Re: [SQLObject] two postgres questions

[Magnus <ma...@th...>]

At 15:24 2003-06-02 +0200, Bud P. Bruegger wrote:
>Agreed.  I tend to forget about pre-existing schemas since I decided
>I don't have a need for this myself.

You probably will one day...

>Well, I understand you philosophically, but what do you mean by object
>identity?

I mean that the object represents something unique in the
problem domain, or in the technical solution. This would
probably also be a design class that I would model in UML
if I choose to use UML. Instances of classes in the code
might not be objects with a unique (logical) identity, for
instance an integer instance in Smalltalk. My idea is that
there should be a one-to-one mapping between this kind of
object identity, and IDs in the database.

Philosophically I mean that there is a distinction between
an object, such as a person or a GUI windows, and a simple
value such as 42 meters or 3612 seconds. Martin Fowler calls
the latter "Value Objects" in his new book. Often, a value
object is simply a scalar like a string or an integer, but it
might certainly be something that won't fit in a simple scalar.

But what I'm after technincally is to map the kind of Python
classes I typically work with in a simple way. Uniform Python
lists and dictionaries are certainly common as attributes. So,
unless I am to contrieve my python object model, I have to map
a logic layer class to several SQL tables.

I guess you could say that if it makes sense to have a foreign
key that links with an object, it *can't* be a value object. I'm
not philosophically certain that this is right, but it certainly
seems reasonable, that anything that we would like to specifically
point out from another table would be more than a mere value. It's
not anonymous any more...

>Yes, I also see these two possibilities.  You haven't been explicit
>about how this relates to GUID or other primary key, so I state is
>more explicitly:
>
>Tables that manage values (as opposed to objects) don't necessarily
>need an OID as shadow information.  Your example is convincing; the
>key of the dictionary is a good solution for a primary key.

Together with the oid of the main object, yes. Like this:

class X so that x = X(), x.a = ['brown, 'green'], x.b = {'a': 42, 'b': 17}
x.c = 'Tree', x.id = 123, I would have

Table x
|id  | c  |
|123 |Tree|

Table x_a
|x_id|index|value|
|123 |0    |brown|
|123 |1    |green|

Table x_b
|x_id|key|value|
|123 |a  |42   |
|123 |b  |17   |

I never want to have a situation where a foreign key is anything
but a single oid field though. If I want to have a foreign key to
a row in a "value table", I would elevate the valur to an "full"
object. This is also aligned with normal object oriented modeling
in UML etc. I can't model a relationship to a plain value in UML.
I can only have a relationshiop with an instance of a class.

If we acually implement these attributes as simple lists and
dictionaries in Python, there will no simple way to keep track
of any ID-fields in the x_a or x_b tables anyway. It seems they
would just be dead weight.

Let's say we do, x.a[1] = 'black', x.a.sort(), and then we want to
save the instance. Now we should have

Table x_a
|x_id|index|value|
|123 |0    |black|
|123 |1    |brown|

I guess I'd just do "DELETE FROM x_a WHERE x_id = 123" and INSERT
the current values. If I had had something like...

Table x_a
| id|x_id|index|value|
|101|123 |0    |brown|
|102|123 |1    |green|

I can't see how this would have helped me... The simple python
list object can't be kept in sync with those id fields anyway.
This id field would just be dead weight, and I'd have to run
the DELETE/INSERT anyway. Right?

>I'm not overly concerned with additional overhead introduced by a ORM
>middleware layer, so I could probably live with an unnecessary GUID.

But it seems it would be dead weight in this case.

>But thinking aloud, maybe there is some systematics to it since also
>breakup tables used in many:many relationships don't need guids...

Right. This is something similar.

>Hmmm.  just an intuition but I haven't understood the systematics of
>it all the way...

There are many ways to skin a cat... :)

I do tend to feel that my logic objects should have an SQLObject
derivate as an attribute, rather than to inherit DQLObject themselves.
I.e. my business objects use some kind of storage objects, they aren't
storage objects. But I might skip this for very small systems.

How do other SQLObject users handle this?

>I had a paper in mind that wasn't listed there, only on OIDs..  But
>thanks for the links..

It's probably among the others at AmbySoft though.


--
Magnus Lycka (It's really Lyckå), ma...@th...
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program