Humberto, I think part of the reason why the schemas are split between turbine and the applications is because TurbineUser is a critical part of the security mechanism and also because there is the basis for retrieving the user information from some place else - e.g. an LDAP server.
I originally copied TurbineUser into my applications schema.xml file so that I could add a bunch of attributes to the table and use userId as foreign keys in my application tables. The down side of this approach is that I often end up coding data.User.getUserId() and passing the result to the object model classes generated by the TurbineUser defined in my application schema - not very efficient because I will often be reading the TurbineUser table twice in a single transaction. The up side however was that I could save changes to my TurbineUser data and associated tables in a single transaction - this is particularly important when you make use of the methods torque generates when it encounters foreign key references to a table. Because of the down side I was never really happy with the above solution and I set aside some time to reimplement the necessary parts of my application in what I thought would be the best way - i.e. extending TurbineUser as documented in the howto. This worked well until it came to invoking TurbineUser.save() which fails to save any of the related objects that may have been added to the TurbineUser object by way of the torque methods generated because of foreign key definitions. These methods are generated and appear to be useful, but at the end of the day they don't perform their advertised function of associating the added data with the TurbineUser record (worse than that, the data is simply discarded). Check this message for details: http://www.mail-archive.com/turbine-user%40jakarta.apache.org/msg03447.html This information should really be appended to the howto. I have actually abandoned the work I did on extending TurbineUser and reverted to the first method until I have aditional time available to consider other possible solutions. Cheers, Scott ----- Original Message ----- From: "Humberto Hernadez Torres" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 18, 2001 10:53 AM Subject: Extending TurbineUser We just finished extending TurbineUser. Thank God for the HOWTO document. YES!!!! It seems to me that it is a very long and painful process for something that it is very commonly needed. If I understood the problem well the root cause of the problem is this: - The Object model for TurbineUser is already generated within the turbine.jar so it has to be extended by hand. - We have a separate turbine-schema.xml from the newapp-schema.xml therefore it isn�t easy to have foreign keys between them. Don�t you think the process would be simpler if the turbine schema were defined within newapp-schema.xml and generated automatically. As a by product the WEB-INF/build/build.xml would be smaller and simpler. This file is probably a mistery for most beginners. What do you think? Is this crazy or just plain stupid? I am sure there may be some reasons to have the schemas divided. -- Humberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
