Previous Entry Share Next Entry
Release 1.2.1
jducoeur wrote in querki_project
This release adds some fixes and enhancements for issues that became obvious after we started playing with Import from MySQL.

If there are many Instances, don't show them all at once. This became apparent when I uploaded my rather large Comics Database, which contains about 3000 titles. The result was that looking at the front page of the Space, or at the Title model, took a pretty long time (~10 seconds), because it was trying to display all 3000 of those at once.

This has now been changed so that these displays only show the first 50 records, followed by a "Show More" link. If you click the link, it shows the next 50. This lets things display decently quickly.

This capability is based on a rather arcane new function named _showSome, which displays a list gradually like this. It's very advanced, and may get replaced down the line, but it's there if you want to use it.

Instances now sort based on their Computed Name. A few months back, I added Computed Name, which allows you to calculate the display name of a Thing based on its Properties. This is crucial for Importing from MySQL, since Things from MySQL don't have Display Name set. Setting up a Computed Name works nicely there, but the list of Things hadn't originally been taking that into account when they sorted those Things. This now works right.

Dates now import correctly. MySQL date columns were importing as the wrong type, with the result that you didn't get the splufty date-picker control when editing them. This now works correctly.

You can now import a gzip'ped MySQL dump. This was a request from Aaron, who routinely keeps his dumps gzip'ped. It also has the nice effect of making the uploads faster.

Finally, there's a new experimental feature: QL expressions can now use URL parameters. That is, if your Querki page's URL ends with "?thingy=42&thingy2=.3y49278", then QL in the page can get at those parameters as $thingy and $thingy2.

To support this, I've enhanced the old and largely unused _withParam function. This lets you pass parameters in a Link, to set those values. It's new and experimental, but works correctly for most common cases.

We'll see if this proves as useful as I hope; the intent is that it should make it relatively easy to build powerful, RESTful pages in Querki. Personally, I am planning on using it to build better queries for my comics. More to come as I learn how that works, no doubt...

  • 1
Ooh. Yeah, that URL parameters thing could be very useful. I may poke at that.

Yaas. For the Comics Space, I figure I want to be able to easily build a page that is "All the titles starting at $Foo", with an alpha index at the front. (Which is what I had on my old Rails site.) And I realized that, while I might eventually build something specialized for this sort of alpha pagination, it should be easy enough to build by hand *provided* I can parameterize the page's URL.

It's a feature I've been pondering for ages now -- indeed, we had it in the old UI, but it was clunky and went away when we switched UIs. The new version is a good deal cleaner: I'm encouraged that it only took a couple of hours to implement. And I suspect it'll turn out to make all sorts of patterns more straightforward...

My first thought though is that there are dangers with adding data through such an unsupervised vector.

My second thought is that this is just the difference between GET and POST again.

My third thought is that there are definitely cases where 'deep linking' becomes possible without having to build dedicated pages to everything you'd want to link to. As in the example you give.

The first is the important one, really, and I crossed that Rubicon last year.

Querki's security model is designed on the assumption that, regardless of whether you're using the official client or not, the other end of the HTTP connection is The Enemy, and is trying to steal All the Information.

The result is that I wound up with an unusual DB access model. Basically, all API calls (that is, everything from the client) get filtered through an Actor named the UserSpaceSession, which mediates this User's relationship to this Space. Crucially, it only allows API calls to access a filtered view of the Space, which has pre-deleted everything you're not allowed to see. So in principle, it shouldn't be possible for arbitrary calls to let you see something you shouldn't.

(The flip side of this is that all writes to the DB go through a single bottleneck, which checks your access before making the change.)

So I'm not too worried about it: frankly, there are scads of other similar vectors already in the system, so I had to find general solutions.

(As for GET/POST -- good point! Hadn't actually thought about it that way, but that's largely true.)

  • 1

Log in

No account? Create an account