> I translate your complaint as: the idMethod should be specified on the > column tag and not on the table.
Yep. Sorry it took so long for me to articulate a fairly simply point. > However doing this is problematic for current users. It is a pretty big > change. Granted. > 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. Makes sense. > 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.) Very cool. Guidgen capabilities would be pretty cool to have. > 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. Hm...okay...the idbroker != autoincrement is still sinking in. > 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. Would you be okay with deprecating/removing the autoincrement attribute on fields then? This might be a little rash, but the autoincrement/idMethod conflict really bugs me. So, Torque assumes that it generates the values for any primary key columns if idMethod=idbroker. Only if they're ints? And if it's idMethod=native, Torque passes the value generation off to the database (leaving the value null). And the database typically handles it via an autoincrement-type functionality, but this means that autoincrement must be specifically turned on via autoincrement=true. So, if using idMethod=idbroker, you just define a pk/int column/table and the identity is done magically by Torque's idbroker. If using idMethod=native, you also have to defined autoincrement=true to let the database know it needs to handle the pk value. (James Turner's patch "fixed" the conflict in mysql only so that if idMethod=native, columns.vm forces autoincrement=true). Sorry if I'm getting redundant, I'm just working myself through the problem to make sure I am understanding it correctly. Hm... Part of what I'd like to see happen with the templates is have some of their logic moved into the Java model, as that's rightly where logic should be, not down in the view (and Velocity was supposed to enforce MVC...ha! :-). So, this change is even more drastic, but the idea is that we could enable backwards compability by making the model smart enough to recognize both types of settings and pick whichever one is applicable. The current style is: <table idMethod=idbroker/native/none ... <column primaryKey=true ... ...or... <column primaryKey=true autoIncrement=true What if idMethod was moved away from table. Torque still bases a row's unique id on the combination of it's primary key columns, but idbroker/native/etc generation is _not_supported at the table level. Instead each column would choose how it's value was populated. E.g. <table ... <column primaryKey=true idMethod=idbroker/native/guidgen ... Hm...so autoincrement as an attribute would be deprecated... Instead, when templates saw idMethod=native, they'd choose how to have the database support it, and usually it'd be via autoincrement. Really, now that I think about it, all it is is moving the idMethod down to column. You gain being able to control multiple pk columns (which is cool, but won't make or break Torque). In an ideal world, I'd be all for it. But realistically, the current solution works. I'm just having trouble adjusting to it. Maybe I skimmed the docs too much on this issue. I'll go see what they said and perhaps clarify them a bit for those who suffer the same misunderstanding I do. Sorry for the long thread about the same old thing. I appreciate your patience. Also, real quick, James Turner's mysql patch adds the assumption that idMethod=native with an pk/int column means autoincrement. Should this be applied across all of the base/*/columns.vm? I'd think it should be an all-or-none thing. Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
