Re: [Openinteract-dev] has_many progress

[Vsevolod (S. I. <si...@cs...>]

Ray,

> (I just looked back at my original proposal and I see that to be 
> consistent with what I just said, I would need to change the 'manual_by' 
> option so that the fetch method does NOT store the retrieved objects in 
> the primary object. We have 'lazy_by' to handle the "fetch into the 
> object on-demand" case.)

Right, then it will precisely mirror the way SPOPS currently works.

> We already talked about changing *_by to reverse_*, so how about 
> renaming my proposed fetch types to something like the following?
> 
>   manual    =>  manual
>   auto      =>  auto_object
>   lazy      =>  lazy_object
>   manual_by =>  reverse_manual
>   auto_by   =>  reverse_auto_object
>   lazy_by   =>  reverse_lazy_object
> 
> Does that help?

This is clearer.

> If so, I think that having the id in the persistent field and the 
> corresponding object stored under some other key, with the id being 
> read-only leads to more potential confusion than just storing the object 
> in the persistent field like I propose. But I suppose this is a matter 
> of opinion. In this case, if you want to set a new value for the 
> secondary object you have to change the object if it's auto/lazy-fetch 
> (since the id is read only), but you change the id if it's manual (since 
> you don't even have the object).

That's another example of config-change-influencing-code that bothers me.

After looking at Hibernate, I think I appreciate the consistency of the 
auto/lazy approach. The problem is that I like the manual approach too, 
but supporting them both makes the framework confusing. I think I'll go 
ahead and start implementing the dual approach, as things can be thrown 
out if needed, but this definitely has to run by Chris.

I probably did not explain well the read-only id approach in Hibernate. 
There are no ids that are foreign keys at all. The only ids visible are 
the proper object ids, and even they are read-only.

Also, Hibernate does let you to add/remove children without saving to 
the database. Once you save the primary object, all the changes to 
dependent objects and collections are saved, and if collection members 
have not changed, they are not re-saved. This actually makes the 
auto/lazy case more consistent, I think.

> Suppose, we change the 'list_field' key to something like 'object_field' 
> and in addition to it's current meaning for reverse direction fetches, 
> we use it for forward direction fetches to optionally specify the key 
> under which to store the auto/lazy-fetched object (i.e. the name of the 
> object accessor). If not specified, the object would be fetched into the 
> same field (just like the original proposal). For saves and removes in 
> the auto/lazy-fetch case, I think the auto-fetched object should still 
> override the id (and we could make the id field read-only in this case 
> as you mentioned).

Sounds good, and see above on ids.

> I'm not sure I understand your example (are you modifying any 
> relationships or just the data?), 

Just the data.

> so it's difficult to say which is more 
> suited, but it seems to me if you are going to do manual fetching and 
> updating, then manual saving should not be such a burden. If the book 
> objects haven't been fetched yet, then they haven't been modified and 
> don't need to be saved either, right?

I'm saying that presumably the framework will generate for me an 
auto-save method that looks like:

sub Author::save()
{
	SUPER::save(); #Calling SPOPS methods for a single object
	foreach my $book ($self->books)
	{
		$book-save();
	}
}

This will only work correctly with cache, though. If the books have been 
fetched before, I will get the same instances. But if you say that the 
code should function equally well with and without cache, than this will 
indeed make no sense in the manual-fetch case.

> If you think the changes I proposed here will satisfy your requirements, 
> I'll be happy to update my proposed spec to incorporate them. For me, 
> having a design written up in nitty gritty detail helps in keeping 
> everyone on the same page and might make it easier for Chris to keep up 
> with all of our discussions.

This may not be a bad thing.

Simon

-- 

Simon (Vsevolod ILyushchenko)   si...@cs...
				http://www.simonf.com

Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.

Zbigniew Brzezinski, U.S. national security advisor, 1977-81