Providing static filters for embedded databases

[AdrianS]

Hi everyone
I’m relatively new to Confluence Cloud, but I worked a lot with Page Properties before.
With Page Properties, we had quite powerful filtering options (labels, multiple properties, etc.).
When i embedding a database into a page, there are some little features missing, which could be make embedded database very use- and powerful.

I would really like to define page-local (static) filters for an embedded database.
Today, filters belong to a view, and changing a view affects all pages where it’s embedded. This makes it hard to reuse the same database on different pages with different perspectives, without creating many views.

And finally, a small UX point:
- When a page is in read mode (not editing), it would be great if the embedded database could show only the table content
- Controls like options, filters, etc. take a lot of vertical space and often aren’t needed for readers

Overall, I really like the direction of Confluence Databases, but these points would make them much more practical for documentation and structured content.
Curious how others experience this, especially coming from Page Properties .

[John Hadaway]

Hi Adrian,
I don't know your background so apologies if I'm just teaching you how to suck eggs. ;)
In this comment I'll refer to Confluence databases as 'CD's to distinguish them from when I talk about relational databases.  I do wonder whether Atlassian could've avoided a lot of confusion by calling  them 'Confluence Views', maybe it just didn't sound so cool?
I think you've already highlighted the key difference when talking about views.  In relational database parlance a view is a selection of data based on filters (e,g, in a PL/SQL statement 'CREATE VIEW AS (SELECT... FROM.... WHERE...)'.  The result looks like a table, but the data is not stored, it's generated 'on the fly', hence you can't 'update' information in views.  The only ways to change the data held in a view are to either update the source data and refresh the view, or change the select criteria of that view. 
So going back to your point about 'changing a view affects all pages in which it's embedded, yes that's right you are changing the selection criteria for the information shown in the CD  so the change will affect all pages where that CD is embedded.  It's a pros/cons situation, once you understand that changes will propagate to all embedded CD instances this can be beneficial.
If you want to reuse a CD (i.e. have CDs with different select criteria) I guess you'd need 'save as' functionality so that you could save a CD with a new name, and then modify the new CD instance.  (I've not looked to see if there is a 'save as' option).  I'd also love to be able to modify the CD criteria using SQL, but maybe I'm just a grizzled old database guy clinging to his familiar well-used tool set.
The key point is that being views, CDs in theory cannot change the underlying Confluence data (in practice Confluence does support dynamically updating page properties via a database... maybe this is an indicator that the devs intend moving towards true relational database functionality?)

EDIT: On reflection I'm clearly wrong about Confluence Databases being 'views'.  CDs are updatable so my logic doesn't hold together... please accept my apologies.

In contrast Page Properties, are metadata properties of Confluence pages.  If you consider pages to be objects, page properties are part of that object's state, so if you change Page Properties like labels, you are changing the state of that page.  This makes page properties incredibly powerful, and provides functionality that CDs just can't replicate in their current state.  I suspect that page labels may be the single most overlooked feature in Confluence, if you get your label structure right the composite search functionality already included with Confluence is a total game changer!

I'd recommend sticking with your tried and trusted Page Properties approach, and considering Confluence databases as untried technology... if they offers clear benefits then use them, but maybe don't become reliant on them.

[MR]

It does seem that Atlassian has already abandoned this potentially awesome “database” capability- so reliance is fraught with risks.  

[MR]

I’d vote for such a feature as I’ve already needed exactly this capability. 

it makes a lot of sense.  Assuming I understood correctly, it should just be a “database view” macro for page specific database view that is stored in the page macro settings. Of course, there are risks with data maintenance which Atlassian likely has to address for this to be user friendly.  And they probably need to finish the public database rest API first.  

[Anne Saunders]

This is the feature request I voted for: CONFCLOUD-79661

Only a handful of my users need to be editing a particular Confluence Database, but I have entries from it embedded in almost every communal space we have. It's not quite the feature I dream of (a "Read-Only, Locked View") but it comes closer than the current options.