> > > > Primary keys are usually defined as unique and not null. Autoincrement > > is something completely different than a primary key. defaultIdMethod > > can say how autoincrement is achieved, but I think only in fields where > > autoincrement is already specified. > > > > So if you have defined a table to use autoincrement and you do not > specify the primary key as being autoincremented, how do you expect it > to get a value? It is redundant info.
That's just it. It doesn't make sense to say "this table uses autoincrement." Autoincrement is a column by column thing, not a table by table thing. Now, granted Torque is an object persistent layer and in most cases any object needs to have some sort of unique idea for the design to make sense, you could say "this object uses autoincrement for its identity." But given that the XML schema is in terms of a database (tables/columns), I think the column by column definition makes more sense. It's just what db users are used to. If we had some schema where you described the properties of an object (e.g. name/description/etc), but _left_ the primary key/identity column (or property in this case) out and instead told the object to use autoincrement as it's identity function, that would make sense. The details of how exactly the object does autoincrement are hidden from the user and it truly is on the object level. But with the table/columns schema, even if you tell the table to use autoincrement, you still have to have a primary key column listing your primary key. This is where the redundant information is (telling the table to use autoincrement but then still giving the column with the primary key). > It would be wrong to define a table as using any type of id generation > and then not expect that the pk is going to use that method. Agreed. Correct me if I'm terribly off here, but I think Torque should automatically use any primary key columns as the unique ids for objects. (I don't know about cases where more than one primary key column is listed.). Regardless of how the table is marked native/idbroker/none and regardless of whether the primary key column is autoincrement. The semantics of the object's unique identity should only be based on the columns that are primary keys. Completely separate from the primary keys being an object's unique id issue, the autoincrement=true/false attribute would control which columns have autoincrement functionality. Regardless if they're primary keys and regardless of what the table's defaultIdMethod is. Once a column has been flagged as autoincrement=true, the semantics of how the autoincrement is carried out is based on the defaulIdMethod of being either idbroker or native. So really, I think the defaultIdMethod should is more appropriately named defaultIncrementMethod. Being from a non-persistence layer background, that's how I thought of it for a long time (and would still like to). > They are separate things in that you can have a pk that is not > autoincremented, but it is wrong to define the table as using an id > generation method, if the pk does not use it. Are you saying the > table's id method might be meant to be applied to some other column? > That is not what I take it to mean. No, I don't see the table's defaultIdMethod having any effect on the unique id of the object. Because the only possible values are idbroker/native/none...any sort of unique id rests solely on which columns are primary keys. How the primary key columns get their data in them (via idbroker/native/or none) should be completely separate from the fact that they represent the object's identity. Currently, if idbroker/native is selected, Torque uses any (all?) of the primary key columns as the unique id. If none is selected, it doesn't use anything. But this can easily be done without the defaultIdMethod attribute. Any primary key column(s) is used as the unique id. If there isn't one, it's as if defaultIdMethod was none. I don't see what defaultIdMethod accomplishes other than acting as a defaultIncrementMethod. > >I think blurring the line and having some > > obscure rule that all primary key/int fields are autoincrement depending > > on what defaultIdMethod is set to will only confuse people. It has > > confused and still is confusing to me, at least. > > There will only be one autoincremented column, when would you want two > autoincremented columns defined as a pk? Divorcing autoincrementing from primary key/object identity just seems like a cleaner approach/architecture to me. I didn't mean to insinuate you'd have two increment columns defined as a primary key, but just that you could freely use autoincrement in a non-primary key field. It's more general and more in tune with what the configuration of the RDBMS is on the backend. Which given the table/column approach to the schema, is important, I think. > How is having a pk made up of one column whose value is generated and > unique conflicting with a basic understanding of db principles? Because db implementations (at least the ones I've worked with) don't tie primary key and autoincrement functionality together. So, to be general and easily comprehendible to newbies, I don't think Torque's schema should tie them together and conflict with what most users have picked up from previous db experience. > I don't > think key generation is a general principle. This whole discussion > makes me think you are wanting to have two columns that would be > autoincremented within a table and these would both be used as a pk. No, not at all. I just want divorced functionality. Not quite sure how the dual autoincremented, primary keyed columns thing came up, but that certainly isn't the intent. I got a little long again, but my basic point is that databases don't tie primary keys and autoincrementing together and assume that any int primary key should be autoincrement, so I don't think Torque should either. If we switched to an object/property schema, I'd agree completely with hiding the autoincrement/primary key stuff. But not in the current table/column approach. Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
