Would like the ability to define the options of a Single-Select or Multi-Select field in one place, and have the definition instantiated/referenced/used in different Types?
Example: Defining a Single-Select field for choosing a “Role Type”, such as:
Content Writer
Web Developer
Project Manger
SEO Specialist
Admin
Sales Manager
Let’s assume I have four different Databases in my app that each need one of these Single Select fields with these exact options.
I want to be able to define this field (the options) in one place, and have this definition used (and updated, should I change it in the future) in each one of my four different Databases that has this kind of field.
This is a feature request created based on this question here:
Hi, Dimitri!
I think in your case it will be better to create a specific Database, called Role
In fact our Single Select and Multi-Select fields are Databases (1-many; m2m) with a friendly UI for simple cases
If that’s not enough - one Database, relations to other Database you want - and you’ll get rid of any limitations, and will have access to visualizations, that didn’t work with Single-select and Multi-selct fields (like Hierarchical lists for example)
Yeah this works very well, but there are two problem with this approach:
1) Its unintuitive - only seasoned Fibery users know that multi-select fields are secretly hidden mini-databases.
Maybe having a normally off checkbox on the single/multi-select field creation modal for something like “Make these options available globally (in other databases)” which automatically does what you suggest, but creates them as “hidden” space/databases. Something like this:
2) It creates a bit of clutter - having to create several spaces/databases just to contain a few entities used as global single/multi-selects creates for messy relationships and clutters up the UI. Because then you have one or more space/databases which really don’t do anything more than hold a few entities.
Also, as was pointed out in the other thread, multi-selects appear in the right hand panel of entity view, whereas a many-to-many relationship (to an enum database) appears as a collection, which is often unnecessary for a simple multi-select functionality.
I just discovered this feature, after 5 months of using Fibery Thanks, it makes things a lot easier. Some questions though:
What I understand is that:
A multiselect field is a mini-database that is part of its parent database X.
The name of the minidatabase is ‘Database X name, Select field name’ (showing at the top of an option view) and that name cannot be changed, and will not change even when the parent database name is changed (confusing).
The database configuration of that mini-database can be accessed by Alt-click opening one of its select options, it does not have a standalone configuration (confusing: am I editing an option or the field)
When creating a new relationship between a select option and another database Y, it automatically includes the minidatabase as field in the database Y configuration page.
However, there is no indication that this is a field owned by another database.
When in database X the multiselectfield/minidatabase is deleted, it is automatically deleted from database Y.
Issues
I think this confusing behavior for users, not transparent or consistent with how databases and entities are configured, and potentially leads to unintentional data loss across databases.
I understand that this feature aimed to create a lightweight solution for categories and select options that dont need the fields and detailed relationship configuration that normal databases have, but I think that it would be better to develop a lightweight database type for such feature.
Suggestion: ‘Taxonomy’, a light-weight database type.
As example, in Drupal they work with the Taxonomy entity type, which is a lightweight version of a Node entity type. However, Drupal has these Taxonomies as stand-alone databases, not owned by other databases.
Or: use relations for everything, and make everything an entity
Apart from that, over the 15 years I’v worked with Drupal I saw that the distinction between Taxonomy and Nodes became integrated into a new bare-bones entity system, where everything became an entity, and working with templates for everything. This gives the needed consistency, transparency, configurability and flexibility, and is in line with what I understand from Fibery’s approach.
By the way, this corresponds well with what’s on the roadmap: Relations as entities, which are also light-weight mini-databases. Maybe some of the underlying mini-database architecture can be shared in sucgh features.
Yes (but improvements to select field config are likely)
Yes
The default name for the field created in Y is the ‘full name’ of the select (i.e. the owning database name plus the field name) so this indicates that the select is ‘owned’ by another db.
Yes
All the things that are missing are present if a user creates a database for global re-use instead of re-using a select field, and I’m not sure what you think a ‘lightweight database’ would have that a normal database wouldn’t have…?
Of course, making it possible to convert a select to a traditional database, combined with the option to hide a db in search, would probably solve a lot of issues.
What I see is that current development in fibery around new features, is focusing on adapted forms of database architecture in order to accomodate specific needs. I mean for example:
Selects
Relations
Comments
File Attachments and Media
Activity Logs and History
Notifications and Alerts
Entity display
Views displays
However, these features are opinionated in the sense that users cannot either create or change them. Benefit is of course a smooth user experience, but the drawback is that fibery becomes a more monolithic and rigid structure, which does not invite users to build or use new templates for custom features like the above.
A ‘lightweight’ bare bones database structure would be one that does not by default include information like custom fields and display and configuration features of current default entities. I’m not a seasoned developer but I can imagine that this is a topic of interest.
personally, I dont use single and multi select field anymore, if I got some things like that, it’d be better to just create an database for that
I’m using a space for all type of single select, or multi select because you dont know which database in the future willing to be used it
Also the custom avatar/emoji make me satisfied when wanna customed gif for status etc…
Per the suggestion, I’ve gotten in the habit of using databases in many cases instead of single/multi select fields. However, there are a few pain points with this, mostly on the UI front:
single/multi select fields can be colour coded and have an icon (though the icon issue I think is already resolved)
single/multi select fields have a very simple display both in the entity view and on other views, whereas relations confuse users because they show up with database icons and the “>” button which opens the related entity. The action to open the entity confuses new users and causes them to lose their current context.
It would be great if you were able toggle on an option to make relation views appear more like single/multi select fields, including allowing them to show-up on the right hand panel and disabling the open action.
Thanks, it makes things a lot easier. Some questions though: