Re: tablename/guid vs. classname/guid

Torben Nehmer <[email protected]> wrote:

> Hi again.

Hi,
 
> >> 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?

Just tell me how to reproduce it. I can not imagine it in real world.
Even with replicated database.
 
> >>>> 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.
> 
> That is the whole idea of "Inheritance" in OOP, remember? So if multiple types
> use the same table they (obviously!) are immediately related to each other,
> forming a relationship. Perhaps like this: class openpsa_contact extends
> midgard_person. The *very same* relationship should be expressable by the schema.
> 
> If this is done, it is (again obviously) neccessary that *both* objects share
> the same GUID, or you break object encaspulation.

Yes, but the approach of "reusable" table is: you have two classes which uses the same 
table. Some columns are defined for class A , some for class B and some for both classes.
OOP inheritance is something else here.
 
Of course I should say "approach" thinking about MgdSchema in 1.7 branch.

> >> 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.
> 
> I see your problem here, although in OOP this should be solvable again.
> 
> In all languages I know of which have a *decent* OO (which rules out PHP), the
> entity creating a class instance knows its exact type (which is why the Factory
> pattern has been developed, for example).

It's not OO related it's related to storage management. And then OO related.
 
> Once more I would like to remind you to think in an OO system, where a number of
>  related types are fully interchangeable *within their hierarchy*. If I have a
> midgard_person, I just need to typecast it to get an openpsa_contact, and *vice
> versa*. No hacks by accessing the DB again getting another GUID. That breaks OO
> mapping to the databases by large.
> 
> We need to carefully decide here how we go, otherwise we might end up in an
> unusable object system in the core.

Yep, I fully agree. However there were discussion to forget about OO inheritance 
till Midgard2. So I did it.
 
> If you are worried by having multiple type declarations accessing the same
> table, forbid it. Plain and simply.

Midgard2 is difficult thing and there are plenty of things I worry about.
*no one* on this world can do its draft from A to Z without mistakes being made
in the middle of the road. 
We are before 1.8 release , so it's better to make changes *now* then between 
1.8.x and 1.8.y.
 
> If not, again my proposal: Bring OO hirarchy functions to the core. I very much
> hope that this GObject thingy can do inheritance, polymorphism etc. Allow adding
> of multiple types per table *if and only if* they are inheriting from each other.

As I wrote I forgot about this for a while :)
 
> But still I think having two distinct guids for the same
> midgard_person/openpsa_contact will make much much much more problems than it
> will "solve". This is the same kind of automatism-strategy, that causes PHP
> itself so much trouble.

I agree, however keep in mind how's the midgard "world" looked like when 1.7.0 
was released. 
 
 * no MgdSchema object browser
 * no support for MgdSchema in midcom
 * admin interfaces ( spider , aegir ) not updated from ages

I think that table sharing was good point to access records from some levels ( somehow ).

> Another reason against distinct guids is, that there are more then enough cases
> (even now) where openpsa_contacts *and* midgard_persons are actually used
> interchangeably. And again they are referenced by Guids. You don't honestly want
>  us in all these cases to get-by-id the new object.

Torben , there's a huge gap between what I want and what I can ( should ) do.
1.7 is development release anyway , and I think it's good branch while it really 
lets anyone to see MgdSchema features preview while not breaking legacy 
applications.
 
> Or to be more precise: You don't honestly want me to bloat the DBA layer with
> *another* workaround for things the core just can't (or don't want to) do.

No, but I will repeat third time :) I forgot about OO inhertiance in core because 
there were such discussion.

> BTW: If I follow your argument, obviously Metadata (which is *conceptually* an
> extension of *each* type) should too have its own GUID.

No, because metadata object is tied to object and its not gettable as standalone object.
 
> > Getting midgard_person record by id as openpsa_contact is a different
> > approach.
> 
> Again, please(!!!!) remember that we wanted to deprecate IDs!

Yes :) that's why I wrote *different approach* :)
  
> > 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.
> 
> I can say the very same thing, just with the exactly opposite arguments.
> 
> Again I suggest you think this through again.
> 
> If you want to "have one table per one type" you (obviously!!!!!!!!!) must
> forbid the case where the same table is reused by another type *if* you don't
> introduce an official means of *extending* an *existing* type. But then again
> the extended types should have the same base GUID. That would mean that OpenPSA
> contacts must be rewritten (which should be not too hard *if* you provide a
> usable API that I don't have to wrap in tons of glue code for a change).

Explain this "if".
 
> But, if you want to allow multiple types to use the same table in different
> ways, you need to think in OO hierarchy terms, where the "identity" of an object
> is more fluid.

Now I lost. I can not understand how OO could help here. 
Indeed OO would bring much more clear readability , but technically you still 
mix up data in table. 
 
 
> > So openpsa_contact should have own table defined but could be able to get
> > "subobjects" content from other tables ( person in this case ).

This is very difficult now. I mean , we have no transactions for database so there's 
a hope that update or create method will work properly.
 
> As I wrote above, it would be much more useful if there would be inheritance in
> the core. There are many roads to solve a problem, and your core should be

Hey, this is midgard core. Not mine.

> generic enough to cover all cases, not just the one favourite you need for your
> personal (semi-OO if I may say that) coding style.

I just do not try to be smarter then semi-OO PHP we focus on.
We can focus on pure OO midgard system with Midgard2 and PHP5 only.

Piotras