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

[Chris W. <ch...@cw...>]

Terribly sorry it took so long to respond.

> Now that Chris has some time (hopefully) to consider the changes, I'd
> like to submit a patch that would add has_many, auto-save/auto-delete
> (optional) and full cache support (which is necessary for the
> consistency circular references). Before I do that, I'd like to get
> Chris's approval on the following architectural decisions:
>
> 1. There will be a basic cache which will always return the cached
> object, not its copy.

Ok.

> 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.

Ok -- although I'd like to have the current behavior available if the
cache is not enabled. (Where it fetches the actual data from the database,
not just the IDs.)

> 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().)

I'm for backward compatibility.

> 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' },

This looks good.

> 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.

Ok.

> 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.

We can tell ClassFactory::DBI to override the has_a from ClassFactory. (I
don't remember how to do it off the top of my head, but I'm 98% sure it's
already built-in.)

> 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?

No -- that's why we have CVS :-) Just use good comments when you commit.

Chris

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.