Re: [Openinteract-dev] Questions about new has_a/has_many/links_to

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

Ray,

Thanks for your comments. I hope you don't construe my comments as 
criticism - they mostly stem from my ignorance of your intent. You have 
clearly spent a lot of time thinking this over.

> So the bottom line, for me is, unless you are in the context where you 
> only have one process running at a time (not the case for my apps), you 
> ALWAYS have to handle the issue at the application level anyway. Having 
> SPOPS do the caching as in (2) can help you with that, but assumptions 
> can never be made at the SPOPS level that even a single cached object is 
> necessarily in sync with the database since some other process may have 
> changed it behind your back.

In general, I agree. It's just it was never explicitly mentioned in the 
docs that the caching mechanism does not return the cached object 
itself, but its copy.

See SPOPS::get_cached_object(). It returns $class->new($item_data), 
where $item_data is the cached object. Of course, if the caching 
mechanism does not store the object itself but its somehow serialized 
representation, the above code would be correct, but I think such 
approach is an overgeneralization.

> My proposal here (found in last section under "Fetch" in my 7/3/01 post) 
> was to pass in the X objects, not the ids ...

I am probably a lazy bum, but the current implementation lets you pass 
the X objects as well as ids, and I found it convenient.

>> 2. You may have noticed that I used 'has_many', not 'has_a' as Ray 
>> originally suggested. I do think it's cleaner to separate them, but if 
>> you insist, I will eventually roll them back into one - I just 
>> separate them now for the ease of coding.
> 
> 
> I'm not sure I've seen how you're using 'has_many' in the configuration. 
> It sounds to me though that it's putting the definition of the 
> relationship at the other end, that's all. Does this then replace the 
> manual_by|auto_by|lazy_by configuration syntax?

I would like to replace the *_by syntax for now with has_many just 
because it's conceptually clearer for me during coding. Like I said, I 
have no issues with using has_a in the final version.

> On this point (and the previous one now that I think about it), my 
> approach regarding where to put the configuration hash was to put it in 
> the class which has the fields. The configuration hash for a class 
> defines the meaning of each of its fields. It can also add behavior 
> related to those fields to other classes. I think it's essential that we 
> are consistent about where we put configuration. You propose putting the 
> configuration in A ... but why A and not B?

No reason. I think it's fully symmetrical, so it can go in any of them. 
It's a tradeoff between a rigorous approach and user convenience, and my 
feeling is that convenience should win most of the time - I've heard a 
well-known Perl figure say that SPOPS is difficult to understand already 
as it is.

> My thought here was that if myA is an auto or lazy-fetched field, then 
> you always assume that $x->{myA} is an object. Otherwise, you always 
> assume that $x->{myA} is an id. You still have a convenience method to 
> fetch the corresponding object if you need it, but even after fetching 
> the object, $x->{myA} is still just the id. It just seemed the most 
> consistent to me. Otherwise, for manual fetches you end up with the case 
> where you don't know when you access $x->{myA} whether to expect an id 
> or an object, since it depends on whether or not you've done the manual 
> fetch.

I see. I guess my problem is that I am not sure why the manual fetch 
mode is even necessary when lazy fetching is available. Could you please 
give an example?

> Why does this require full caching? Maybe an example would help. I don't 
> think any of what I proposed requires caching, just the assumption that 
> consistency is being maintained, with or without a cache, by the 
> application level logic.

This issues stems from the same problem with the caching mechanism 
returning multiple copies of the same object. However, if caching is 
non-mandatory, then avoiding circular saves needs another approach. It 
has to be implemented via a hash that is either passed around among the 
arguments to save() or stored globally, and for each object that has 
been saved a value corresponding to the object's class name and id is 
stored in this hash. If the class name and id are already there, then 
the save operation is not performed. However, I'd rather not mess with 
the arguments of save(), which leaves the global hash. It's not pretty, 
but I think it's the only remaining solution.

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