Re: [Openinteract-dev] has_many progress

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

Simon,

On Dec 6, 2004, at 9:11 PM, Vsevolod (Simon) Ilyushchenko wrote:
> Another weirdness-inducing thing is that with your auto- or 
> lazy-fetching, we effectively have a limited cache, as the fetched 
> objects are stored in the hidden fields, but with manual fetching we 
> do not have a hidden cache. Thus, simply changing SPOPS config will 
> change the code behavior, and it may not even be noticed at once 
> during compilation (unlike the id-to-object change), because the lack 
> of caching only rears its head when you fetch the same object more 
> than once. No matter how much you document this, it's not obvious for 
> a beginner, and thus the warnings will be ignored.

I don't see why this is so difficult, even for beginners. I think you 
are confusing things by thinking of it as a cache. A cache is something 
that sits between you and the database and intercepts fetch requests to 
avoid going to the database. That is not what we have here.

We have two types of methods, accessor methods and fetch methods. In 
both the manual and the auto/lazy case, the object's accessor methods 
simply return what is stored in the Perl object. In the auto/lazy case, 
you expect these to be secondary objects that were fetched previously 
and stashed. In the manual case, you are simply saying that you don't 
want to store any secondary objects inside your primary object. So you 
don't expect to have any accessors that return objects. You still have 
convenience methods to fetch these objects, but these are "fetch" 
methods, not accessors.

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

> Your example with DateConvert which is also a configuration change is 
> not quite in the same league, because then you are clearly changing a 
> datum type. But a switch from auto- to manual fetching would look very 
> innocent to a beginner.

I think that putting the "manual implies id, auto/lazy implies object" 
very prominently in the documentation should be sufficient, but you 
seem to think not. Can we come up with something other than 
'manual/auto/lazy' for the fetch type that captures the differences in 
data type as well as differences in fetch behavior?

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?

>> No storing objects in fields?  You mean you want to eliminate  
>> auto/lazy-fetch as an option?
>> Ah ... wait a minute ... are you assuming a cache?
>
> No, that would be even more weird. However, note my comment in the 
> previous email that the foreign key ids may be made read-only. This 
> will eliminate a way to create inconsistencies.

OK, now I am confused ... I must have missed what you mean by not 
storing objects in fields. If you're auto-fetching something that isn't 
going into cache and you're not storing it in the object, where is it 
going? Or did you just mean that you store it in the object under a key 
that isn't a persistent field?

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

How about this ... would the following change to my proposal allow you 
to do exactly what you want?

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

I don't personally see the need for the additional complexity 
introduced with this option, but I guess it's not so bad ... just more 
to document and more for new users to digest.

I *think* this would let you do what you want without preventing me 
from doing what I want, right?

>>> How do we deal, though, with manual fetch (when a dependent object 
>>> is  not stored) plus auto-save (when a dependent object/id should be 
>>>  stored to be saved)?
>> This issue is also addressed in my proposal in the e-mail referenced  
>> above. Since you can't auto-save an object you don't have, 
>> auto-saving  with manual fetch makes no sense, and attempting to 
>> configure a field  that way should throw an error.
>
> Actually, I can think of a situation when it does make sense. Suppose 
> you edit a web page listing info for an author and all the books he 
> wrote. First you retrieve the old author and book objects from the 
> database, then you replace some values, then you save the author 
> objects and would like the book objects become updated to. Even if 
> they have not been fetched yet, they would get fetched when get an 
> array of children to iterate over.
>
> You'll say that this is more suited for auto-fetching, but I may still 
> want to use the manual fetching for the "neatness" reasons. :)

I'm not sure I understand your example (are you modifying any 
relationships or 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?

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.

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