Navigation trail: [TurbineProjectPages] - [JakartaTurbine2] - [Development] - [JakartaTurbine2/Proposals|Proposals] - [Turbine User]

Proposal to change the implementation of TurbineUser

Many users of Turbine need to extend the TurbineUser object. They either need to create FK references from thier own tables to TURBINE_USER or they want to store more data in that table. We have a working how-to document on how to accomplish this but it is still a complicated process. The approach even has a few defects that are dicussed at the end of the how-to where the patch is supplied. We have had several people asking for an updated patch or inquiring if the current version includes the patch.

To make matters worse, there is a turbine-schema.xml file included with Turbine. Torque will happily generate the OM objects based on that file. These objects are not even used!! Granted, there is a reason for the file. It is used to create the database schema.

I think that Torque should be used to generate the code for TurbineUser and all of the other tables. Of course, this presents a few problems. For instance, o.a.t.om.security.TurbineUser implements the o.a.t.om.security.User interface. Leaving it to the user to implement that interface is worse than the current solution.

If we did use Torque to generate those objects and we used them, there would be no reason for the how-to. It would be simple and easy for the users of Turbine. Also, what about when Torque supports other persistence methods such as OJB? Are we going to have two versions of TurbineUser?

I know that this is a difficult problem to solve. One of the main problems is that RunData and the SecurityService depend on the User interface being implemented in the TurbineUser object. We also support using LDAP in place of the database. We should also be able to support NT authentication and other solutions as well. This was probabley one of the driving factors behind TurbineUser storing everything the the perm hashtable leaving it to TurbineUserPeer (which would only be used for people using the database implementation anyway) to pull the data out of the hashtable and store it in the correct columns.

I think that Henning makes some great headway on this issue with his version of the security service. With his version of the security service, the column names could change. It could be taken a step further, possibly, to allow either primative or object types to be used as well. This would eliminate most of the interface defined the User.

Only the access counters, temp hashtable, and persistent pull tools would be left. I did not mention the perm hashtable because the need for it would completely disappear if adding columns were as easy as adding columns to the tables definined in project-schema.xml.

The access counter stored in the perm hashtable could simply be moved to its own column.

The session acces counter and everything else in the temp hashtable could be moved to a session pull tool. I know that session pull tools are store in the user temp hashtable but this could (and should, IMHO) be changed. A better place might be the session itself.

Persistent pull tools... If it were not for backward compatibility, I would say drop support. However, we could make the column in TURBINE_USER table in which these are serialized into configurable. This would not be any more complicated than the changes Henning has already implemented in his new version of the Security Service.

I think that about covers the issues involved with using Torque generated objects with the database version of the security service. I am not sure how this would affect LDAP, if at all.

Comments?