Re: [Openinteract-dev] has_many progress

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

Ray,

> Right. Except that 'list_of_authors' in $book implies that you've 
> specified a reverse fetch of the book field in author, so 
> $author->{book} is just an id, not an object. More on object vs id below.

Okay, this is my last stumbling block. I just don't get why you want to 
  sometimes refer to the object and sometimes to the id. If it's 
implemented this way, I'll have to say $author->book->id instead of 
$author->book_id for auto/lazy, if I want to to just get the id value. 
Also, if I switch from auto/lazy to manual fetch, I'll have to change 
my code.

Can you give me an example of manual fetch that cannot be implemented 
otherwise or that makes life more convenient? Manual remove, OTOH, is 
clearly different from the other two methods of removal.

> But I don't think there is anything in the new has_a design that 
> REQUIRES one to maintain consistency though an SPOPS level cache, right? 

Aww, who am I to argue with developers? I'll make sure both cases work.

> I think the only thing you need to do is ensure that you don't have any 
> auto-fetching loops (might even want to include lazy-fetching) when you 
> do the configuration. In other words, you don't want to have a book 
> auto-fetch it's list of authors AND have the author set to auto-fetch 
> its book, creating an infinite loop. Even if you use a cache this would 
> cause circular references which cause a problem for garbage collection 
> unless you use weak references.

Hmmm... circular references will actually come up even without circular 
configuration. If an author refers to a list of books, and the books 
refer back to the author, there you have it...

> I think this checking is important, but I haven't honestly given any 
> thought to how to implement it.

I'm currently doing this checking during saving/removing objects. The 
configuration allows loops - I'm afraid that if this is prohibited at 
the configuration stage, the potential for error is too great.

> I vote once again that we stick with my proposal to use 'fetch_' 
> prepended to the name of the field, by default, and allow an option to 
> explicitly specify a method name.

Okay.

>> This should not be a problem, because in my current proposal the 
>> programmer specifies either has_a or has_many (which implies the 
>> reverse has_a), so no conflicts should be possible. However, if we 
>> change the syntax, this issue will go away.
> 
> 
> But since you can put a 'has_many' in Book and a 'has_a' in Author, for 
> example, where Author has a 'book' field, I think they can be 
> inconsistent. In my proposal you, for the 'has_a' in Author, you either 
> specify a forward or reverse direction with no way to specify something 
> conflicting in the Book class.

Who's to stop the developer from saying that Author has_a Book and Book 
has_a Author?

>> 'Link_class' refers to the Perl class name, 'link_class_alias' - to 
>> the method name used to retrieve its instances (this is your 
>> 'list_field' in the 'link' hash).
> 
> But can't you always get the one, given the other?

No, the alias can be overriden by the user.

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