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.  

[AdrianS]

Conceptually, this is currently a bit difficult to place.
It seems to sit somewhere between classic database views and configurable SQL query options.
As a result, it is not entirely clear how it should be properly classified or used.

In principle, I see value in both approaches: a central view that is deliberately maintained in one place and affects all embeddings,
as well as individual, static custom views that allow data to be filtered in a targeted and stable way.

[John Hadaway]

In theory you can 'kind of' apply static filters to Confluence databases by creating new databases that link to your source database.

So for example I have a CD Collection database with a unique reference field called cat-ref. 
I could create a new 'All Rush CDs' database which uses a linked item columns to link to the CD collection and a linked field column to replicate the cat-ref field (call this artist_ref). Plus linked Artist and Album fields that link to the corresponding fields in CD Collection
If I then look up all the rows in CD Collection for the artist 'Rush', and enter the cat-ref numbers into artist-ref in the All Rush CDs database I should get back only the CD Collection database rows for Rush albums. 
If I create a third database (it's getting complicated now!) called Search Rush CDs, which links to 'All Rush CDs' and link to all rows, I've now got a read only view of 'All Rush CDs' database
Someone using the 'Search Rush CDs' database would still be able to filter it, but they would only see Rush album data, so it is a kinda static filter'  Downside (and it's a big one!) is you'd have to manually manage all of the database links.  Maybe manageable for 'one off permanent static views, but a right pain if it needs regularly updating!

However you probably noticed that insidious 'in theory' caveat at the top of this comment.

When I tried to implement this so that I could give far clearer instructions (I recognise the above aren't easy to understand) I kept getting "Oops, something went wrong" errors.
I think the (badly described) theory is good, however it's 'Nice idea, but no cigar!" if the practical application blows up!

I'm glad I could err... help?

Better idea, forget databases and take a listen to Rush's Moving Pictures album, it's a classic!!

[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.