Re: tablename/guid vs. classname/guid

Torben Nehmer <[email protected]> wrote:

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

midgard_person Old ID 17 has GUID A openpsa_contact Old ID 17 has GUIDB

I just try to understand why , when and how such thing happen. Should I?

If you use id as primary field then you can not have two different guids for the same record
in the same table. If you use guid as primary field you do not have to worry about ids 
because they can be the same ( even as primary fields, theory  ).
And if you use guid as primary field you have two different records and thus two different 
objects. 

The problem with my listening is that I must listen to everybody. 

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

Yes, that's why you have objects and classes available on PHP level instead 
of functions set,  for any types registered in schema. 
I know that we need OO inheritance , but it's not easy now as we do not have
powerfull storage management.
 
> > 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.

Example please. Except table sharing.
 
> Of course, I may be wrong, given that there are no specifications around except
> the old read-the-source rule.

What specifications are missed? Core's one? midgard-php ones?
Please elaborate.

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

Torben , I do not want to ask you about listetning to me as you ask me about this.
And I do not want ( and I am far from it ) to start any long spam thread between me and you.

I wrote that my problem with listening is that I must listen to everyone and there was
discussion to forget about OO inheritance in core till Midgard 2.0 is out.

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

Yes I can read this book and others as well. But it doesn't change the fact that OO
and table reusing  comes down to mixing up the data.  It doesn't solve any problem 
which is tiggered by the fact that few types ( inherited or not ) use the same table as
storage. 

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

We decided to use libgda. And we will use it since 1.9. So please wait till 1.9 is out.
 
> 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. :-(

Torben, believe me or not , but now we are at this moment of midgard development
when I almost forget when I last time developed any midgard-php code.
It was written once and luckilly we change plenty of things without any need to 
change higher levels. 
OO in midgard is getting better and better.  

EOT for me. We can only vote for  table (not)sharing.

Piotras