[Modeling-users] using Modeling w/o primary keys

[Duncan McGreggor]

Hey folks,

I've got kind of an insane question... insane because Modeling is so
good, and I have a need to use it in a very limited fashion.

One of my clients wants to rollout support for Modeling in their python
applications, but wants to do it without support for primary keys. The
reason for this is that they are pulling meta-data out of databases
(i.e., basic column definitions for tables) but not anything regarding
relationships. They want to create attributes/properties of entities
based on this, and then use these models to programmatically manipulate
live data in the database.

Is using Modeling w/o support for primary keys possible? I have been
trying to do something like this, but it violates rules for valid
models in Modeling, and as such, it won't create any .py package model
files. My attempts at tweaking the code to disable support for PKs have
been catastrophic, as it seems it is woven into the very fabric of the
software. Is there a crazy hack I can use until the client is ready to
support primary keys in the meta-data extraction process?

Thanks for any help or advice!

Duncan

[Sebastien Bigaret]

Hi Duncan,

Does this mean that you need to access an already existing database where *no*
primary key are defined???

PKs are important, yes, just because you need a PK to map an object w/ its
corresponding row in the database (even if you do not have a single
relationship defined in the schema). Any objkect-relational mapper will need a
way to uniquely identify a row/an object (it does not mean, however, that there
should be an attribute explictely marked as the PK in the db, only there is
exists a set of attributes (generally one) that can be taken as the PK).

I bet you have PK defined in your tables, or am I wrong? Secondly, could you
tell whether you wish read-only access to the db? (I suspect you do, but better
be sure).

-- Sébastien.

Post by Duncan McGreggor
Hey folks,
I've got kind of an insane question... insane because Modeling is so
good, and I have a need to use it in a very limited fashion.
One of my clients wants to rollout support for Modeling in their python
applications, but wants to do it without support for primary keys. The
reason for this is that they are pulling meta-data out of databases
(i.e., basic column definitions for tables) but not anything regarding
relationships. They want to create attributes/properties of entities
based on this, and then use these models to programmatically manipulate
live data in the database.
Is using Modeling w/o support for primary keys possible? I have been
trying to do something like this, but it violates rules for valid
models in Modeling, and as such, it won't create any .py package model
files. My attempts at tweaking the code to disable support for PKs have
been catastrophic, as it seems it is woven into the very fabric of the
software. Is there a crazy hack I can use until the client is ready to
support primary keys in the meta-data extraction process?
Thanks for any help or advice!
Duncan

[Duncan McGreggor]

Post by Sebastien Bigaret
Hi Duncan,
Does this mean that you need to access an already existing database where *no*
primary key are defined???

Most of their tables do, but some don't. The ones that don't may just
be lookup tables, in which case there's no need to model them... The
project has been a "black box": they want a generalized wrapper for
some of their custom utilities, so os tools, and Modeling. I've been
getting more info from them, though...

Post by Sebastien Bigaret
PKs are important, yes, just because you need a PK to map an object w/ its
corresponding row in the database (even if you do not have a single
relationship defined in the schema). Any objkect-relational mapper will need a
way to uniquely identify a row/an object (it does not mean, however, that there
should be an attribute explictely marked as the PK in the db, only there is
exists a set of attributes (generally one) that can be taken as the PK).

Yes, as you can see, not only does what you say make perfect sense, but
I am rather ignorant of database modeling below anything other than a
purely superficial level.

Post by Sebastien Bigaret
I bet you have PK defined in your tables, or am I wrong?

I don't have access to their databases, but have the understanding that
most of them do, but some don't. Based on what you said above, I think
it's perfectly acceptable to perform a PK check during metadata
extraction, and throw an exception for any table without a PK.

Post by Sebastien Bigaret
Secondly, could you
tell whether you wish read-only access to the db? (I suspect you do, but better
be sure).

You would think, based on my initial question, that it would be
read-only. If I have known what I was talking about, I would not have
asked the question... your answer and questions are very instructive: I
see now that in order for object mappers to be able to manipulate and
save data back to the database, there must be primary keys (or some
means of object identification).

Given that, I will write the code necessary to extract PK info from db
metadata tables (postgres and oracle), and use that to create a db
model. I'll give that a try and see how it works.

I don't know if any of the client tables have multiple columns that
define PKs, however, I just did a search on the mail list and saw this:
http://sourceforge.net/mailarchive/message.php?msg_id=6801413
Has there been any move to support multi-column PKs since then?

Thanks for your patience and help!

Duncan

[Sebastien Bigaret]

Hi Duncan,

Fine, it seems this could make it for that appication(s) you were
talking about. We'll probably get more info& questions soon ;)

I don't know if any of the client tables have multiple columns that define
http://sourceforge.net/mailarchive/message.php?msg_id=6801413
Has there been any move to support multi-column PKs since then?

We've not moved an inch since then; as I usually say, I now do not have
the time to develop things if this is not at least a user's request,
just because I think features needs to get real-life testing to become
quickly mature and robust. And even then (when people need the feature)
it can sometimes take quite some time to implement --optimistic locking
is a good example.

So, again, if you have the need for the feature and at least a "test"
application ("test": from the framework's point of view :) then tell
us and we'll probably make a step forward!!

Now, to be completely honest, having "raw" support for compound PK
should not be a real problem, however for now I cannot foresee how much
we could get in trouble wrt relationships based on compound PKs. But
since you said that your own needs by now won't use relationships, then
you can be optimistic if this is a feature you definitely need!

-- Sébastien.