Re: tablename/guid vs. classname/guid

Torben Nehmer <[email protected]> wrote:

> > SELECT typename from repligard , create new object instance and get_by_guid 
> > ( the same guid used as function parameter ).
> 
> Great, but now you have a problem:
> 
> midgard_person Old ID 17 has GUID A
> openpsa_contact Old ID 17 has GUID B
> 
> How do you represent this in the DB when the ID column holds the GUID?

I know that weird things may happen in midgard db , but how you want to make this?
I have no idea how to reproduce it.
 
> >> Wouldn't it be better to always return a "base type" (using scenario 1) and let
> >> the application decide what it does.
> > 
> > We should have some schema stack then. ( oh, did I say stack? ;)
> > This forces us to make special language bindings hacks.
> 
> I suspect you're talking about inheritance / extensions. Would be a good thing
> as we have talked about it.

No , I am talking about lack of knowledge which type is base and which is not.

> >> I see the benifits of both implementation, but I fear the side-effects of the
> >> possibility that a single db object has multiple guids across the types.
> > 
> > I get Your point , and frankly speaking I think both scenarios are bad then.
> > But it also depends how classes constructors work.
> 
> Well, for one thing if you stay at scenario 1 you have two cases:
> 
> a) The code author knows what type he is looking for, in that case I use the
> correct class name anyways.

More or less. If I know what is the type I want to work with I make its instance 
and invoke its method.
 
> b) The code works on arbitary objects, then you need the lowest common part anyway.
> 
> Another thing is that you can no longer treat the various object types
> synonymously. When the openpsa_contact gets another guid then the
> midgard_person, you loose the ability to easily cast up or down between the objects.

These are two different objects and should have different guids. Using the same table 
is up to application developer. Anyway , when you created midgard_person with guid X
you shouldn't get this object as openpsa_contact with guid X.  
In such case guid X represents only ( and only ) midgard_person.

Getting midgard_person record by id as openpsa_contact is a different approach.
 
> The more I think about it, the more potential problems I see when you give types
> sharing the same table different GUIDs.

One guid one object. If we want to make it *stable* and  without any potential problems
we should have one table per one type. Once registered table shouldn't be reused by another type.
Getting "content" from other table should be resolved by midgard content proposed by you.

So openpsa_contact should have own table defined but could be able to get "subobjects" content
from other tables ( person in this case ).

Piotras