On Sun, 2002-10-20 at 10:26, ingo@... wrote:
> AFAICT, the ids MiddleKit uses to link objects in different tables
> don't refer to the target table's "id" field, directly. That makes it
> hard to edit the tables using conventional, relational database
> editing tools because they can't link up the objects.
> Is that accurate or a bug? (I'm using the experimental PostgreSQL
> adapter) If thats correct, could it be changed or is there some
> requirement to have it like that?
The high 32 bits of an object reference are the class id, and the lower
32 bits correspond are the serial number of a specific instance of that
class. The class id is necessary because of subclasses; the object
reference _might_ be to class A, but could also be to class B if B is a
subclass of A.
There was some talk a few months back about splitting up object
references into two columns, classid and serial num, instead of stuffing
both values into one column. This would make ad-hoc SQL admin easier,
but AFAIK hasn't been implemented (yet).
For development, I've extended MiddleKit so that you can dump your data
to a Samples.csv file, which can then easily be edited with a text
editor, and reloaded using MiddleKit (generate, create schema, insert
data). I can send it to you if you like; I plan to commit it to CVS but
it may take a while for me to get to it.
If I need to do data admin on my production server I usually write a
stand-alone python script which uses MiddleKit to access/modify the
Jason D. Hildebrand