On Saturday 24 November 2001 03:27 pm, Luke Opperman wrote:
> What is the current state of MiddleKit? I like what I've
> read so far, curious how the database location is
> specified, curious how object inheritance is represented in
> a relational model. I'm very comfortable with complex
> relational join's and modeling... It will take a little
> readjusting to think of the same solutions in an object
> model (assuming possible..). Besides MiddleKit, what other
> ways are people dealing with database access?
The arguments you pass when creating the store are passed onto the DB
API module. So you have your usual keyword args like host, username,
etc. The database name is derived from your model.
If I remember my terminology correctly, we are using "horizontal
mapping". In any case, the key points:
- 1 SQL table per concrete (eg non-abstract) class
- each table has all attributes including inheritance
- obj references use a a 64 bit id (32 bit class serial num and
32 bit obj serial num)
- lists are down with back "pointer"/ref attributes
MKs largest weakness is unsophisticated list handling.
It has an excellent test suite and is very stable. I use it in 2
I also use the MK object model to generate views and forms and sample
data for my objects. You may find other creative uses for the object
BTW If you don't like the 64 bit obj refs (and if you don't that's
probably due to working with existing databases), simply don't use the
"obj ref" type in your model. Or use it, mark it as isDerived, and
implement the method that retrieves it.