The use of both idMethod on <table> and autoIncrement on <column> is redundant. It makes no sense to have
idMethod=none, autoIncrement=true on some column idMethod=native/idbroker and no autoIncrement=true on any column (The second one makes sense, if you can assume the intent is that the one and only pk column is the one to be generated. But based on your argument that this should not be assumed, it makes no sense.) I translate your complaint as: the idMethod should be specified on the column tag and not on the table. However doing this is problematic for current users. It is a pretty big change. I don't like calling all types of id generation "autoIncrement" either. I read it as a specific type of id generation, where a column has some internal way of keeping track of the next id that is not exposed to the user (like mysql does) and this id is an integer that is incremented for each inserted row. Other db's such as oracle have special structures called sequences that can be used to get a value for a column. IDBroker is a modification of a high/low generator that works with a single column pk. It is correct that it currently hands out keys that generally increment, it is possible for a higher value to be inserted prior to a lower value, however. There are other id generation schemes such as guid that do not generate keys that can be said to increment. (I did write a guid generator for torque, but I did not get to the point of integrating it completely and it is sitting in the t2 embedded torque version.) more inline > > 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. That is what torque does. > > 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. Again idbroker does not have anything to do with autoincrement. idbroker is defined in terms of the table and it is not possible to have more than one pk or any other column other than a pk defined to use idbroker. > ... > 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. This is wrong. Torque always uses the all the columns defined as pk to create the unique id. Its just that it expects the schema to be well behaved and only have one pk column, if it is using a generated value. > > 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. > The pk is or at least should be the minimal set of columns needed to define a unique row. I don't think it makes sense to use autoincrement outside a pk. It may be possible, but I would like to know of a good reason to do so. If you have an autoincremented column it is the minimum set needed to uniquely identify the row. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
