Re: tablename/guid vs. classname/guid

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

Hi Piotras,

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

Will you start listening? This is not about reproduction, why else would I use
Future tense.
>> 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.

I was under the impression that we were building an OO system. Sorry if I'm
mistaken, if you again start to produce a semi-maybe-something-like-OO system,
please tell me, so that I can start looking for an alternative for midgard. :-(


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

You do understand that storage management in an *Object* persistance layer is
tightly related to OO concepts?


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

While that may be true you should always *design* the system so that it can be
implemented later on. What you're doing now raises the impression in me that it
isn't done that way.

Of course, I may be wrong, given that there are no specifications around except
the old read-the-source rule.


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

Midgard 2 is a difficult thing and there are plenty of things I too worry about.
*No one* on this world can do its specification completly without errors being
made during the process. We are before 1.8 release, any change we made now
should be in a way so that it survives 1.9, 1.10, 2.0 and not just 1.8.1, 1.8.2
etc. Therefore it is of upmost importance to take future developments into
consideration carefully.


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

Midgard 2 is a difficult thing and there are plenty of things I too worry about.
*No one* on this world can do its specification completly without errors being
made during the process. We are before 1.8 release, any change we made now
should be in a way so that it survives 1.9, 1.10, 2.0 and not just 1.8.1, 1.8.2
etc. Therefore it is of upmost importance to take future developments into
consideration carefully.


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

So what?


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

And it will be in the future whenever and wherever backwards-compaitbility is an
issue.


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

I know, and there is a huge gap between what I can do and what I'm *willing* to do.


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

Midgard 2 is a difficult thing and there are plenty of things I too worry about.
*No one* on this world can do its specification completly without errors being
made during the process. We are before 1.8 release, any change we made now
should be in a way so that it survives 1.9, 1.10, 2.0 and not just 1.8.1, 1.8.2
etc. Therefore it is of upmost importance to take future developments into
consideration carefully.


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

Piotras, you habit of not reading precicly what other people write starts to get
a bit on my nerves.

I underline conceptually here.


>>> 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* :)

I do not find this funny.


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

To put it simply: If you don't want to have multiple types per table, forbid it.

If you want it, tie it to the OO conceptes inherent for an *object* persistance
framework. Provide an API for it that solves problems not by introducing new
problems.

I cannot put it simpler.


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

Recommended reading:

http://www.amazon.com/gp/product/0201633612/
http://www.amazon.com/gp/product/0201700735/
http://www.amazon.com/gp/product/0201309564/
http://www.amazon.com/gp/product/0471242136/


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

Then make transactions an requirement. Mysql 4.something supports it, other DB
backends as well. Specifically I find transactions being one of the *most*
important DB layer things which are missing after the invention of the QB and
the coming introduction of DB-abstraction.


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

Yes, where the new core is mostly written by you, which brings me to the term
"your core".

As MidCOM core is mostly "mine", which is why I find that I have the moral
responsibility to stand up for the stability and production-worthyness of the
MidCOM core.


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

Midgard 2 is a difficult thing and there are plenty of things I too worry about.
*No one* on this world can do its specification completly without errors being
made during the process. We are before 1.8 release, any change we made now
should be in a way so that it survives 1.9, 1.10, 2.0 and not just 1.8.1, 1.8.2
etc. Therefore it is of upmost importance to take future developments into
consideration carefully.

[and]

I was under the impression that we were building an OO system. Sorry if I'm
mistaken, if you again start to produce a semi-maybe-something-like-OO system,
please tell me, so that I can start looking for an alternative for midgard. :-(


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

iD8DBQFD6dzcJPh4Kn6d5FYRAugCAKDjcjIn6PJJyUoyOvmgP9mIfhHHHgCeLDk+
9Liq7qiDoPdQb9015fAcRhM=
=p1bM
-----END PGP SIGNATURE-----