Re: [Openinteract-dev] Review of proposed changes and a question

[Ray Z. <rz...@co...>]

Hi Simon,

It's good to hear that this work is coming along ...

On Oct 21, 2004, at 11:32 PM, Vsevolod (Simon) Ilyushchenko wrote:
> 1. There will be a basic cache which will always return the cached 
> object, not its copy.

This sounds like a good idea. This ensures that, within a given 
process, there is only ever one copy of an object in memory no matter 
how many times and in what contexts you fetch it, right?

Just curious, at what level are you implementing this cache? Is it 
*always* used for all SPOPS objects? Only for DBI? Only for DBI when 
you are using the new functionality?

> 2. The fetch_many() now will also use cache. It will still make a call 
> to the database, because it won't know which ids to request from the 
> cache, though.
> 3. Auto-save and auto-delete are off by default. This is not what Ray 
> requested, but it's the only way to stay backwards compatible. With 
> auto-save on, the graph of object in memory will be traversed to 
> determine what has been changed. (Thus, I have deep_changed() instead 
> of changed().)
> 4. It will be possible to use a separate class that corresponds to the 
> linking table in links_to (think ClubMembership). The syntax I came up 
> with is:
>  Club => {
>     class        => 'Club',
>     ...
>     links_to        =>
>       { 'Person' =>
>             { table         => 'ClubMembership',
>             link_class => 'ClubMembership',
>             link_class_alias => 'memberships',
>             alias => 'members',
>             to_id_field   => 'member_id',
>             from_id_field => 'club_id' },
>
> The ClubMembership class can have extra attributes (like date), but 
> they will be specified in a regular way in the config file. The new 
> attribute 'link_class_alias' will return an arrayref of the 
> ClubMembership instances. Again, this is not as elegant as Ray 
> proposed, but backwards compatible.

I'd like to give my feedback, but I'm not sure I have a clear 
understanding of which pieces of my proposal you implemented exactly, 
which pieces you implemented with small modifications, and for which 
pieces you chose an alternative approach entirely.

Do you have a documentation detailing the new syntax for the 
functionality you are adding? Actually, possibly the simplest thing 
(and probably the most helpful thing for me) would be to just take the 
examples at the end of my proposal and modify them to your syntax so I 
could see an example of what each case looks like.

I forgot, did you implement any lazy loading features or is it just 
manual and auto?

If I understand correctly, one of the fundamental differences between 
your implementation and my proposal is that for has_many and links_to 
relationships the definition of the relationship is no longer specified 
in the class containing the linking field, but rather in a class that 
is linked to. I'm a bit concerned that with the way I use SPOPS (not to 
create classes but simply to define the relationships and persistence 
of traditionally defined *.pm-file classes, where linking classes have 
not only extra fields, but also extra functionality), some of the 
functionality I need which was present in my proposal will be missing 
from your redesign ... but I guess I won't know until I see the 
details.

In any case, your actual working implementation is far better than any 
un-implemented proposal, so don't get me wrong, I really appreciate all 
the work you've done even if it doesn't end up covering everything I 
would have liked.

> An open question is what to do with has_a. Currently it's implemented 
> in ClassFactory, not ClassFactory/DBI, but adding auto-save and 
> auto-delete functionality requires the has_a code to be DBI-aware. I 
> can add extra functionality into ClassFactory/DBI, but I am not sure 
> which effect it would have on LDAP storage, for example.
>
> Oh, and a style question. I have marked all of my changes with "tags":
> #Simon
> #/Simon
> and I commented out, not deleted, all replaced code, for ease of 
> reference. Is this necessary?

Might be nice initially for Chris to see this, but I'd think eventually 
he'll want to remove it. But of course, that's Chris's call.

> I will grudgingly remove lc-ing of field names. I love it, but, as 
> pointed out before, it will break existing code.

Thanks, this is appreciated since it was my existing code that was 
breaking.  :-)

Thanks again for your contributions,

Ray Zimmerman
Director, Laboratory for Experimental Economics and Decision Research
428-B Phillips Hall, Cornell University, Ithaca, NY 14853
phone:  (607) 255-9645