Re: [Openinteract-dev] has_many progress

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

Chris,

Your approval is eventually needed here.

Ray,

> Again, I think you're just saying that you want manual fetching. Why  
> would you configure it for auto/lazy fetch if all you wanted was the  
> id? If you only need the object sometimes and want the parent() method  
> to always return an id, you can still always get to the object using  
> the fetch_parent() method (which you can even rename if you like).

I think this finally got through. Even before reading the end of your 
email, I realized that, indeed, I am describing what you call "manual 
fetching". I was objecting to the presence of the word 'fetch', but I 
should be able to rename the method in the config.

> Unless I don't understand what you're suggesting, I think this goes  
> back to our previous discussion about what to use for the config key,  
> alias (old has_a syntax) or field name (new has_a syntax). Those  
> aliases are only unique to the class, but we need something unique to  
> the field to be able to handle the case where you have two fields which  
> belong to the same class.

Well, class alias and field name can be combined. My point is that a 
field is an integer and an object is an object, and I don't like mixing 
their names. In fact, the idea of substituting objects for ids (in your 
auto-save case) still weirds me out, even though I see where you are 
going with it. I'd like Chris's input on this.

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.

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.

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

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

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