Re: tablename/guid vs. classname/guid

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again.

- --Piotras wrote on 2006-02-07 18:34:
>>> 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.

This is not weird. I am just talking about what we were talking for the future
Midgard 2: The deprecation of IDs in favor of GUIDs. We said that we do no
longer want that distinction, thus changing the id column of each table to GUID.

Which *implicitly* means that GUIDs are table-wise, not type-wise.


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


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

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

This always leads up to the point where there is some place in the code which
knows precicly what type to load. But thing is, that this decision is very very
context dependant. I know of not a single DB persistance layer which can do this
decision for you magically.

In this respect:

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

I also see this problem, but it is not a problem that can be solved in the core,
as for each example where you want two guids per object I can give you another
example where it would only hinder you.

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.

If you are worried by having multiple type declarations accessing the same
table, forbid it. Plain and simply.

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.

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.

An important thing here is that you should introduce automatisms only if they
can really cover at least 99% of the cases, not just 50 or so. Please don't let
Midgard get another unusable software system like PHP itself.

You cannot decide about the final type in the core anyway, even in MidCOM core
there are at least half a dozen classes inherited from MidCOM core object
(excluding those added by the DBA code generator). These types are unknown in
the core, and thus I need to decide about final type *anyway*.

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.

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.

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


> Getting midgard_person record by id as openpsa_contact is a different
> approach.

Again, please(!!!!) remember that we wanted to deprecate IDs!


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

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

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.


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

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


Live long and Prosper!
Torben Nehmer

- --
Torben Nehmer, Guenzburg, Bavaria, Germany
http://www.nathan-syntronics.de, mailto:[email protected]
PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6ZoDJPh4Kn6d5FYRAhtmAJ4q9zVdcQlbZMfdpWLdazK4+J+fXACggIDx
BLHf05G47z29Ap3XXZZQ3wM=
=cSOT
-----END PGP SIGNATURE-----