I would like to see the ability to define and enforce property types as required, and then the type, like a SQL database. I think more people would be able to move from Notion if this was implemented, because the risk of creating an error in Logseq with a missing or incorrect property value is preventing a migration to this great project for me.
For example, in my intended CRM/project management use-case, if I enter:
project_invoiced:: ture
instead of:
project_invoiced:: true
I may not even notice until it causes a bigger error down the chain. If this example had a defined Boolean type requirement, Logseq could render the Block Error warning if the user clicks away while a required property value is missing, or it is the wrong type.
I think a JSON Schema approach would be a good way to tackle this, maybe in a seperate schema.edn file where the user could define and enforce global property value types? This could also help teams migrate from Notion once the collaboration features are implemented e.g. if a team admin could enforce correct data entry and minimise mistakes through property validation, that would add to the value of the project for teams.
Enforcement should include at least these three factors, in my opinion:
I think the more logical extension of this concept includes setting constraints on the type of data availabel in a property. For example, Obsidian has preset options for property types, which allows us to choose “Checkbox” for a property type, limiting it to the Boolean true/false options like you’re suggesting.
Taking that a step further, Obsidian users can use a plugin called “Metadata Menu” to do some advanced property configuration.
For example, I could create a new note that’s just a list of options I’d like to have available in a property called “status”, let’s say the note looks like this:
Pending
Ongoing
Reviewing
Closed
I can point Metadata Menu to the list note and those four options are the only ones available when I attempt to change this property value.
An even more advanced option, which I’d really love to see implemented in Logseq (particularly since the querying functionality is built-in, instead of bolted on the way Dataview is with Obsidian), is the ability to limit the options for a given property to the results of a Logseq query. So if I have a meeting, I’d like to have a property for that meeting block called parent that is limited to a query showing only the pages matching a pre-defined query.
Hi,
With the upcoming database version, property types and allowing a user to define and choose certain property values will be supported. Required and custom validation are good ideas that could make it into the database version sometime
