[dev] postgres ltree and DataTree/sql.php

[Chuck Hagenbuch]

Quoting Matt <matt at kynx.org>:

> Seeing as DataTree is so central to Horde, it seems like an excellent
> fit. But I'm a little stuck on the structure.

Does sound like it'd be a nifty structure. :)

> Ideally the tree column would contain as much info as possible that gets
> searched on. Right now horde_categories has:
> group_uid | user_uid | category_name
>
> I think these should get rolled into one ltree column, creating a
> structure something like:
> horde.groups.user1.sales
> or
> horde.shares.ansel.user2.mygallery

Definitely not user_uid - that's just a record of who created the 
entry; I'm not
really sure it's even used anywhere.

> But there seems to be a fair amount of inconsistency about how that
> group_uid column is actually used. Most apps seem to create a level
> under horde.shares, but some like giatepo go completely their own way.
> Am I missing something here? And does this also touch on the guid
> discussion from a few days ago?

Not really. But it depends on what the kind of data is. All shares are 
stored in
horde.shares, but Giapeto isn't creating shares; it's creating pages/page
structure. DataTree isn't specific to share data.

So, you *could* combine group_uid and category_name if you wanted.

> I think I should be able to work around the existing structure without
> breaking the apps which rely on it, and provide a conversion script for
> existing db's, but I'd be interested to hear if anyone has other ideas
> on/plans for the existing group_uid col structure.

One thing I was considering was having the SQL driver be able to create one
table per group_uid, in order to optimize a bunch of queries. You could
probably work with that idea (optionally), too.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez