Previous Entry Share Next Entry
Release 1.2.6
querki
jducoeur wrote in querki_project
Today's release (and release 1.2.5.1, a bugfix release a couple of weeks ago) are mostly odds and ends. Here's the rundown.

Enhancements

(Only interesting to techies) Really, the only thing that was *really* an enhancement this time around is pretty innocuous from the user's point of view, although it's important internally: OID allocation is now sharded.

What does that mean? Well, OIDs are the unique numbers assigned to each Thing in Querki -- for example, when you see ".3y284n2", that's the base-36 representation of an OID, which is a big number. The problem is, historically we've been assigning those using a database transaction each time, and that doesn't scale well: it means that the database record containing the next OID is very "hot", and as the system scales up, it would turn into a bottleneck.

This has now been completely rewritten. Each node in the Querki cluster is now assigned a unique "shard ID", and is responsible for creating its own OIDs. These are now created using Akka Persistence (which will likely become the core underlying tech for the whole system next year) -- basically an append-only journaling DB that works without big transactions. It's also optimized to not require a DB transaction every time. (Basically, the DB allocates blocks of OIDs, so only needs to be updated every now and then.) This should make the system better-able to handle things as we move to the new cluster.

This is *mostly* invisible to you, except that the actual OIDs you will see are now different -- instead of everything starting with ".3y2" the way they've always done to date, they will start with ".5x3" for the time being, and will become less predictable going forward. (.3y2 is the old shard, that is still being used to create new Users; everything else has been moved to the next shard, so the numbers are now all bigger.)


Also, a minor tweak: Edit Width is now visible for all Properties. That is, when you create a Property, or edit the Property in the Model/Advanced Editor, it will now show Edit Width as one of the meta-Properties you can change. Edit Width has existed for a fairly long time, but I've found that it's useful enough to make it worth being easier to use.

When you edit a Thing, it shows all of that Thing's Properties. Those Property Editors each have a default width, but sometimes you want to customize that, to make the Thing's overall Editor look nicer. (For instance, if you know that this Text Property is always a short name, you may not want to spend an entire line on it.) So the Edit Width of a Property is how wide that particular Property will show up in the Editor. It can be set to any number from 1 (fairly narrow) to 12 (the full width of the page).

Techies should note that this is the width in Bootstrap terms (the col-md-n class), and if you really want to play power games with building custom editors, you can do fancy stuff with that.


Bug fixes

Lots of bug fixes this time around.

Pagination in Edit Instances is now fixed. When you Edit Instances from a Model, if there are more than 10 of them, it gets paginated. The UI for this got broken a while back; it now looks correct again.

Redundant Done buttons don't show up any more. Historically, the Instance Editor has always down a "Done" button at the bottom, which displays this Thing. That's appropriate when you're editing a single Thing, but is generally more headache than help when you are showing a page that has multiple Editors in it. (For instance, the Edit Instances page -- it's been all too easy to accidentally hit one of these "Done" buttons and leave the page when you don't mean to.) This has been rewritten to only show Done when it seems really useful.

Computed Name now works more consistently. Computed Name is one of the more powerful features in Querki, and one that I've increasingly found to be important. You want to use this Property if you have Things that really don't want their own Display Names -- where the Display Name really wants to be derived from *other* Properties. For example, in my Comic Book inventory, I don't want to give a Display Name for each Issue -- I want to say that the Display Name is [[Title]] #[[Issue Number]]. You do this by using Computed Name instead of Display Name.

(Why two different Properties? Frankly, just because Computed Name is *vastly* more expensive to compute.)

Computed Name's been around for a while, but I've now fixed a couple of edge cases. In particular, when you have a Link/Tag Set Property pointing to a Model with Computed Names, the Tag editor now finds those links properly. Also, those Things with Computed Names now display properly in the Link/Tag Set Editor.

The Choice Order Property now only shows the valid options. This is a stupid bug that has been bothering me for ages. Choice Order is a Property that you can put onto a Model that says, when showing a List of its Instances in the Editor, what order to show them in. Heretofore, unfortunately, when editing Choice Order *itself*, it would show you all of the Things in the Space, even though only the Instances of that Model actually made sense. This now works as expected.

(This will all be obviated in a while -- we'll be adding a wizard for defining Choices, which will subsume the Choice Order Property. But until then, best to have this working right.)

Naming a Model "[[" results in an uneditable Model. The first of two doozy-level bugs found by Eric this week. In this case, the bug is actually more general: if you created a Model whose Display Name consisted *entirely* of non-alphanumeric characters, and you tried to edit it, you would wind up editing, no shit, the constant "True". This turned out to be the intersection of three different little edge cases, all of them now fixed. It is now the case that a Thing whose Display Name is made entirely of non-alphanumerics doesn't get a Link Name at all, which makes everything work right.

(Note that names like this aren't recommended for Models -- it makes them harder to refer to in QL expressions, for example. But it's legal, and shouldn't be broken.)

Changing your login in one window now updates your other windows. This is a pretty long-standing bug. Say you have three windows open in Querki. You log out of one of them. The other two would still show you as logged in, and let you do logged-in sorts of things, but most things you tried to do would fail because you weren't *really* logged in any more. I can't count the number of times I've gotten horribly confused by this.

We now update the Client with your current login status on every API call, so changes to your login in one window get reflected in the others as soon as you do anything in them. This makes things a *lot* less confusing.

The Search box now only shows when you're in a Space. Pointed out by Chad -- when we switched the Your Spaces page over to the new client, it picked up the Search box at the top, same as all the other pages. Problem is, Search doesn't *work* unless you're currently in a Space. (We might someday add Querki-wide Search, but that's a *big* and fairly hard project, and a long ways off.)

So the Search box now only shows when you're actually in a Space, so it makes sense.

If you deleted a Model that had Instances, all hell would break loose. Eric discovered this last night, and I realized the scope of it this morning; it was the cause of a Sunday release, since this *needed* to get fixed. Basically, if you deleted a Model that had Instances, not only would the Space become unstable, it would no longer load again once it had gone to sleep.

(NB: if you ever find that a Space won't load, please tell me *instantly*: that's the definition of a crisis-level bug, and must be fixed ASAP. This is the first time I've seen it happen in a long time, and it is always unacceptable.)

Anyway, dealing with this entailed several separate fixes. First, I fixed the problem that was actually causing the error. (Basically an internal exception when the system found a Thing whose Model couldn't be found.) This now treats the Thing as being a Simple Thing under these circumstances, even though it isn't really.

Second, I added a new _orphanedInstances command, which is shown from the Actions -> Advanced... page. When an Instance gets orphaned like this, it doesn't show up in most of the standard displays, so this is how to find it, so that you can Change Model to something real.

Finally, the Delete dialog now detects when you're trying to delete a Model that has Instances, and warns you about that specifically. Also, the resulting message after you do so tells you to go to Actions -> Advanced... to find the orphans. I'm not actually making it impossible (at least not yet), but I want to make sure it doesn't happen by accident.

We might eventually make this more sophisticated -- for example, not allowing you to delete a Model without changing all of the Instances to some other Model first. But it'll always be possible to get into this state via the API, so the above fixes are there to help if you get into trouble.
Tags:

?

Log in

No account? Create an account