Okay, I'm going round in circles thinking about the best way to handle this, so I figure its time to get some more opinions...
I'm looking at bug #545622; basically the problem is that the create methods I generate in the DAO don't include a reference to the bean, so you can't update values in the bean with ones you read back from the database after you've inserted the record. Originally, I was thinking that all methods (including the lifecycle ones) would be able to pick and choose if they were in the DAO, by whether or not you put the @dao.call tag on them. However, because the load/store/remove methods needed extra arguments so that the DAO could get at the bean's PK & fields, rather than put in a bunch of tests for those as special cases I just included them automatically (and you shouldn't use a @dao.call on them). I'd hoped the create methods could be dealt with as they were, allowing you to choose which (if any) would appear in the DAO. But it seems this isn't the case. As it stands, the generated DAO create methods don't allow for e.g. setting extra fields in the EJB to the values filled in by database defaults, because it doesn't have a reference back to the EJB that called it. No problem, I thought, I'll just automatically add the create methods, same as load/store/remove, and include the reference to the EJB. Besides, if you've specified to generate a DAO for a BMP bean, then surely you'll want the creates to be using it anyway? Problem solved. But then I changed my mind again :-) Previously (with non-DAO based BMP) I often had various create methods with a partial set of the fields all calling a single one that had all of them (passing nulls or some other suitable default for the rest). In cases like that, it only needs the method with all the fields to be in the DAO, and adding *all* creates automatically won't allow for this. So maybe I do need to check for @dao.call after all (which means special-casing to filter them out of the loop that's doing the rest of the DAO call methods, which I dislike). The current workaround for the fact that the DAO's create doesn't have a reference to the bean is to include a helper method in the EJB that has the @ejb.call tag and which does include a bean reference as an argument, and have your ejbCreates call myCreateHelper(this, args...). This kind of allows for the above case too, since rather than most of the ejbCreates calling a single one, they're just all calling the helper. So the problem is solved without changing anything in the template, it just needs documenting somewhere that this is how you should be doing it. And I'm back to where I started... Lastly, it occurred to me: with CMP, you just set the fields' values in the create method and leave the rest to the app server. Why not try and have the DAO-based creates work the same way i.e. set the values in the bean class' ejbCreates and the generated BMP class subsequently calls the DAO? Easy enough to do, just have the DAO calls in the subclass check for non-abstract super before calling the DAO (in fact, what the hell, it might as well do this on *all* dao.call methods). Plus, if we rely on people setting the fields' values in the super ejbCreates, the generated DAO could just have a single create method taking just the EJB reference as its argument, and all the ejbCreate methods in the BMP subclass can call that method since they don't need to pass the rest of their argument lists. No need for a helper method at all. The down side is, what if they want a create method that has an argument which can't be stored in the fields (though I can't actually think of a case when you'd want to do this). So, what's the best/neatest way of doing it? 1. include all creates anyway, 2. only include creates with @dao.call and special-case them in the main methods loop, 3. assume a helper class and document it, or 4. assume they'll set the fields' values in the EJB's ejbCreate methods (and document this)? Andrew. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
