For those of you that are attempting to extend TurbineUser to make
use of TURBINE_USER.USER_ID as a foreign key in your application
tables here is the latest problem I have run into - it actually intersects
with another thread titled "autoincrement and key retrieving".
Torque generates some pretty useful code that enables you to add
related objects to a common parent object and then save them all
to the database in one transaction. You can do something like this:
OrderDetail od1 = new OrderDetail(500, "item1");
OrderDetail od2 = new OrderDetail(100, "item2");
Order o = new Order(clientId);
o.addOrderDetail(od1);
o.addOrderDetail(od2);
o.save();
This is very helpful - you don't need to worry about the ids that
connect the child rows to the parent rows and you don't need to
worry about the transaction necessary to insert these into the
database as one atomic operation. It also provides:
o.save(dbConn);
which can be used when you have other data you want to commit
in a transaction you are managing yourself.
Now here is the problem. After extending TurbineUser in the manner
described in the committed to cvs, but not yet on the site Extend User
Howto
(http://cvs.apache.org/viewcvs/~checkout~/jakarta-turbine-2/xdocs/howto/extend-user-howto.xml?rev=1.3&content-type=text/
plain)
methods to add records related the extended user class, but the data
itself is ignored when ExtendedTurbineUser.save() is invoked.
Following the example in the howto:
Rdf rdf = new Rdf();
data.getParameters().setProperties(rdf);
NewappUser user = (NewappUser) data.getUser();
user.addRdf(rdf);
user.save(); // !!!! rdf is not saved !!!!
Of course replacing the last two lines with:
rdf.setCreateUserId(user.getUserId());
rdf.save();
will in fact save the Rdf, this is beside the point - the other method
addRdf() shouldn't exist if it doesn't work and this is a trivial example.
Further, there is no equivalent save(dbConn) method provided to
allow this update to be combined with others within a single database
transaction.
The answer is going to be something along the lines of implementing
a custom UserManager (perhaps by extending DBUserManager),
but the problem here is that UserManager is designed to be storage
medium agnostic (e.g. retrieving a user from an LDAP server
rather than the database) and hence it does not include methods
specific to database storage.
I am unsure right now how to proceed. I think for the moment I
am going to abandon this approach and go back to redefining
TurbineUser in my application schema so that I can retain the
benefit of the torque generated code (at the cost of having to
retrieve user records a second time).
Cheers,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
