Chuck Esterbrook <[EMAIL PROTECTED]>:
>
> On Thursday 14 March 2002 08:25 am, Magnus Lie Hetland wrote:
[...]
> > Does this sound doable (and, if that, useful)?
>
> There are some other packages out there that are higher level than DB
> API, but still lower level than MiddleKit. Can't remember the names,
> since I use MiddleKit all the time, but before you crank this out, you
> should search the db-sig mailing list and the Vaults.
Hm. OK, will do.
> But regarding your approach, how will you account for attributes that
> should NOT be stored.
I basically envisioned using the classes as thin wrappers where
everything set explicitly should be stored. Each instance would just
be a table row with Python syntax, basically.
> It sounded like your setattr/getattr approach was
> going to do everything. My experience with any archiving solution is
> that there are often a few auxilliary attributes that I don't want to
> archive in some of the objects.
Well, in that case I guess I'd just create another object with a
reference to the persistent one.
> I suppose you could make use of
> getstate/setstate like the pickle module does.
Hm. Haven't had a look at that.
> Also, you mentioned that no mapping needs to be explicitly specified.
> However:
That was the idea, yes.
> sql database
> table Department
> code char(10)
> name char(100)
>
> table Employee
> dept char(10)
> name char(100)
> salary float
>
> How would your mapper know that employee.dept should return a
> Department object, not a 10 character string?
I wouldn't dream of using a 10 character string in the first place.
I'd use a foreign key, probably using an id (int). That would go for
any object references.
> Prehaps this is something
> that "foreign keys" in Postgres could help indicate. I'm not that
> familar with them.
That's what I'd do, yes. (I find them indispensible; I guess you can
easily use that sort of thing in e.g. MySQL too, just without the
consistency checking.)
Basically:
sql database
table Department
id integer (serial)
code char(10) # Possibly redundant...
name char(100)
table Employee
dept_id int (foreign key pointing to Department)
name char(100)
salary float
I guess foreign keys aren't really necessary either -- any column
named foo_id could be interpreted as an object reference to an object
of class Foo (stored in the table foo), where every object reference
is represented as an integer ID.
> Other ORMs that support existing databases still end up providing for
> explicit configuration in order to handle object references, lists,
> implicit joins for those things and other things.
I don't think I'd need it for my application. (And, btw, Postgres
supports array columns, so I could even store lists directly... Though
putting them in a separate table wouldn't be that hard, I think.
Again, naming conventions could help out.)
>
> -Chuck
--
Magnus Lie Hetland The Anygui Project
http://hetland.org http://anygui.org
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
