Data Model

Open Stories and Issues

A child Instance of an Instance does not display in All Things: This is hard to set up, but if you manage to create a child Instance of another Instance, it won't show up, so it's hard to know it's even there.
As a Querki Dev, I can declare and use a typeclass: Not quite sure what this means yet, but use plus and sum as a good example.
I can filter / define a backlink Property: This is still a bit vague, but the core notion is that we probably want to provide better support for cross-links, such as the "Stories" property here.
I can replace *any* Property Value with a QL Expression: Huge, powerful and terrifying, but clearly correct. This would be the Querki equivalent of the common notion that, at the interface layer, a property can be either a value or a function.
I should be able to *easily* pass parameters to linked pages: The high concept is that, if My Page expects to receive a parameter, I should be able to simply specify the link as My Page, and pass that parameter semi-magically.
I should be able to change an ExactlyOne Property to Optional: It is not unusual to create an ExactlyOne Property, fill in a bunch of data, and only then realize you don't need to fill that Property every time. So it would be helpful to be able to change it to Optional.
I should be able to change the Type of a Property: Only where it makes sense, but we should at least be able to change a Text Property to a Large Text, and vice versa. In the longer run, we should have as robust a Type-conversion system as we can manage.
I should be able to customize the list of Instances of a Model: Initially, a List of Instance is just Display Name links, but we can do better. By default, it should just list the Display Names and links as it does now, but add an Instance List View that can be applied to a Model, which produces the default way to view an Instance in a list of them. This is a very common concept, as it's turning out, so we might as well establish an official mechanism.
I should be able to delete a Model Type: Currently, it just can't be done -- the back end forbids it.
I should be able to delete a Space: This should require a big confirm button, obviously, and only be available to Owner.
I should be able to edit Things that I create: The current security model has a hole: if I have Create privs, but not Edit, then I create a Thing and immediately can't do anything with it!
I should be able to filter the Instances of a Model: The page that shows me all the Instances of a Model should also provide me with a set of filters that I can easily apply to them.
I should be able to list all the Instances of a Model: Currently, we list all of the Instances on the Model's page itself. They should probably exist on a separate page, linked from there, so we don't over-clutter the model's page.
I should be able to restore an Archived Space: This is probably a function from the Archived Spaces page.
I should be able to say what happens when I delete a pointed-to Thing: This comes up when we look at seriously importing MySQL, which allows you to specify in a foreign key constraint what happens if the Thing I point to gets deleted.
I should be able to see a list of my Archived Spaces: Probably a button that shows up on Your Spaces if you have anything archived?
I should be able to set a "current default value": Consider my Comics Space. I want to be able to say "I am currently working on Maybe Sell Later", and have that default applied to all Issues I create for the time being.
I should be able to specify a Validation Filter for a Link Property: This would be a Function on a Link Property. When you edit a value of that Property, only values passing this filter would be offered.
I should get (at least) a warning if I make Instances more readable than their Models: Currently, using the fine-grained Security system it's entirely straightforward to make a Model Owner-only, while allowing others to do things to its Instances. That mostly doesn't work.
I shouldn't be able to just delete a Model that a Type depends upon: Closely related to I should be able to delete a Model Type. This might be higher priority, since it's potentially Space-wrecking -- we can initially just check and forbid it in SpaceCore.deleteThing.
I want to be able to use the same name for a Model and the Property that points to that Model: Very, very often, a Model exists to be linked to. It is just plain confusing to need to have a Model named "Country", and name the Property Color Link the same.
It is possible to create a Model Inheritance loop: Create a Model "Loop 1". Add a child Model "Loop 2". Add a sub-child model "Loop 3". Set "Loop 1"'s parent to Loop 3. Boom! Immediate stack overflows.
Need a _deduplicate function: Eric has a use case involving _withValueIn(), where he is feeding in a collection with a lot of duplicates, and is winding up with an enormous, unmanageable number of duplicates. I think the behavior is technically correct, but he doesn't have a way to produce workable results.
This could be addressed by having a simple _deduplicate function, which takes a QList and returns a proper QSet, removing all duplicates along the way.
Need Links with Metadata: It would be very useful to be able to have Links that contain additional fields, so you could say more about this particular relationship.
Querki should have a single, unified "Number" type: We currently have Whole Number Type, Large Number Type and Floating Point Type. That makes sense from a programmer POV, but none at all to the end user -- they're just Numbers.
The architecture of SpaceEvent management should make sense: This is an enormous Epic, for the long-term redesign to make both Experiments and Offline Mode possible, and to make Publication Mode saner.
The names of the Types shouldn't include "Type": This is just plain awkward, the way that all the names include "Type" -- in the drop-downs, for example, it looks weird.
Turning off Who Can Read on a Type Model is likely to cause errors: That is, if User U can't see a Model (due to Who Can Read), which is used by a Type used by a Property used by a Thing that U can see, they're going to get errors.
When I reify a Tag in a complex Schema, I should be asked which sub-model I want: Pointed out by Eric: if a Tag Property is pointing to a Link Model that is the parent of sub-Models, it is ambiguous which Model should be reified.

Closed Stories and Issues

_instances should return the list pre-sorted: You want the results sorted at least 90% of the time, so we should just do that and be done with it.
Data corruption when saving or loading Instances that have Lists of Models: Reported by Eric in May '18; finally repro'ed by me on 5/24/18. Still narrowing down the recipe, but it is clearly that we're seeing corruption when we reloading Things that have Lists of Models.
From a Model Value, I should be able to access the enclosing Thing: This is a subtle but significant problem pointed out by Eric. Sometimes, when you are building a sophisticated Model Type, you really want to be able to access contextual information that exists on the enclosing Bundle. For example, in his highly-customized Review Types, he wants to be able to display the current Average -- but the Average Property is on the Thing, not on the Review, and the Review currently has no way of getting to the enclosing Thing, even in workaround.
I can't recover from a Model Loop: If I manage to create a Model Loop -- a circular dependency -- there is no way to recover, because things crash too early.
I should be able to archive a Space: Note that I'm not worrying about accessing archived Spaces quite yet; I just want a way to clean up a bit.
I should be able to ask whether a given Thing is descended from a given Model: Requested by Eric, this is essentially the _isa function.
I should be able to browse and restore Things that have been deleted from my Space: This needs some design, but in principle it is a pretty straightforward enhancement to the History mechanism.
I should be able to cause Property changes in QL: Crossing the Rubicon here: introduce a _changeProperties() function that updates the Space.
I should be able to change the Collection of a Property: In particular, I should be able to go from ExactlyOne to Optional, and switch between Set and List.
I should be able to create a Date or Duration literal: Currently, these are way too hard to create. In particular, Duration usually wants to be a literal in practice.
I should be able to enhance a Type Model in my Child Space: In the current design of Apps, Type Models are rigid: you can't modify them in your child Space. That's unfortunate.
I should be able to have a Model Property override characteristics of some of the constituent sub-Properties: This is extremely advanced, but it would be quite powerful to be able to consider Model Types to be "parameterized" like this.
Issues not pointing to Titles in Comics Space?: DEATHLY CRITICAL: something is very, very wrong. Everything looks fine when I am doing the data entry, but it appears broken when the Space reloads!!! Worse, the older Issues look fine -- it's just the new stuff that's broken. And the brokenness is that these Issues have links to their Titles, but those links have illegal OIDs. All of which suggests that the OIDs are being saved wrong, which is about as bad as bad gets. This needs to be investigated and fixed immediately.
Model View should not be NotInherited: Eric uses sub-Models more heavily than anyone else, and his sub-Models actually don't change the structure so much as they do identity. So this lack of inheritance is a pain.
Refactoring Spaces and Changing Models: So, I've just hit my first major refactoring issue. I've defined Hero, Villain, and Environment as top-level Models. I realize now, though, that what I really want is a top-level concept of Deck, with children Hero Deck, Villain Deck, and Environment Deck. Now, at this stage, I haven't entered so much data in the existing structure that it would be ludicrous to redo it all if need be. But this seems like just the first instance of something that will happen frequently in Querki, and may want a more robust way of addressing it.
It seems to me that users will need some way to either:
  • change what Model a Thing is based on, or
  • some semi-automated tool to help them migrate large amounts of data from an old Model to a new one.
[Alternatively, to solve the particular issue I'm facing, it might make sense to create some way for a "Link Model" to point to a collection of Link Models, rather than 1 or nothing.]
There should be a more-efficient way to look up which Things have particular values in their Properties: See the documentation of _withValueIn -- this story is a retrofit for that new function, which I decided I need for Backbone.
Undelete messes up ownership and history: I believe the problem is that Undelete is implemented as "re-add". It needs to fix these fields as it does so.