[dev] DataTree patch - Last

[Carlos Pedrinaci]

On Fri, 2004-04-23 at 17:44, Chuck Hagenbuch wrote:
> Quoting Carlos Pedrinaci <cpedrinaci at yahoo.es>:
> 
> > Ok, here you are the latest patches all together in a tar.gz.
> > These patches include:
> > - DataTree changes
> > - SQL scripts changes
> > - History adapted
> > - Groups adapted
> > - Shares adapted
> > - Links adapted
> > - Agora adapted (Forums and Messages)
> >
> > Still remain Perms and Signup from framework and the rest of modules.
> > Is this looking any good or am I wasting my time?
> 
> Carlos - I'm really sorry I took so long to get a look at this.

No problem :)

> 
> I'd really like to see this done a different way, one that doesn't 
> require this
> many modifications. I'd suggest something like an optional use of the
> datatree_data field to specify the classname, or perhaps an attribute that
> specifies the classname (you'd have to be able to fetch attributes, 
> check them,
> load the object, then translate them)?
> 
> For one thing, dropping datatree_data will lose anyone's Trean bookmarks as
> things are now, so that's a bad thing. The serialized field might indeed be
> able to go, though. And it seems like we shouldn't have to store the classname
> along with every single datatree object.
> 

I have done it that way basicly because I understood you were looking
forward for getting rid of the serialized data stuff. I thought that was
the moment for doing so, as I was playing around with datatree stuff. 
My idea was to couple all kinds of migration scripts with the patches so
as to avoid those issues, but I must however admit that I haven't
checked yet at every horde module thus I don't know all the issues I
might have to deal with.

> Finally, storing a file path in the db seems problematic; it'd mean 
> never being
> able to change file paths, etc.

This is definitely an inconvenient of the pathes I've sent.
To solve that I was thinking about using the constants that defines each
application's base (THOR_BASE, AGORA_BASE etc..). 
I'm still unclear about how to re-use them in a nice way... but I'd say
that would be the solution for that.

> 
> Basically, I really like the idea, but not the implementation.

Okay :) 
I'll re-think it

Carlos