Paulo Schlup Santos wrote:
Hi Bartek,
Paulo thank you again for the answer, unfortunately it still does not help.
I have seen something like this happen in PostgreSQL, but on Oracle it's working just fine for us. Did you try cleaning your target directory with "maven clean" and building your app again? I've found out that it solves many problems with inconsistencies among torque classes.
Certainly I tried, several times. No result, unfortunately...
The only other thing I can tell you is that we have put tne idMethod="true" on both dataset and table xml tags, and that the uppercase "M" *does* matter in the "idMethod" keyword. Also, the keywords "autoIncrement" and "primaryKey" should be type exactly as I've put below, with capital "I" and "K" respectively.
I am sure my schema is correct, since the Peers and MapBuilders for SecurityService are generated correctly (with 'native' idMethods set).
It is important that the problem concerns only the security-related objects, which suggests that prior to registering TableMaps generated by Torque, the o.a.t.util.db.map.TurbineTableMap (a TableMap for DBSecurityService) is invoked, which registers all security-related tables with 'idbroker'.
Finally I've found the bug. It was my negligence: I adopted an old Flux plugin, dating back to T2.1, to T2.3. It is quite easy to make it working, but I omitted a single constant from o.a.t.om.security.peer.TurbineUserPeer, which makes a classloader to load the class, initialize all its static fields (with MAP_BUILDER!), and subsequently override DatabaseMap entries with DBSecurityService specific solutions. Instead, the o.a.t.om.security.User constants should be used.
With best regards, -- Bartosz Walter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
