|Subject:||The fancy new entity-auto service execution engine|
|From:||David E Jones (jone...@hotwaxmedia.com)|
|Date:||Jul 27, 2008 12:28:14 am|
For those who didn't catch this on the commit list...
In SVN revs 679058, 679288, 679301 I committed a few changes to make it easier/faster to implement common CrUD (Create, Update, and Delete) services. The basic patterns are demonstrated in the services.xml file in the example component, and there are extensive comments in the Java file that implements this service execution engine as well (org.ofbiz.service.engine.EntityAutoEngine).
Basically just set the engine attribute to "entity-auto" and the invoke attribute to "create", "update", or "delete".
The most complex one is the create operation, and there are 4 variations of depending on how many primary keys you have and on whether or not each is defined as an IN or an OUT to identify a primary sequenced ID, a primary sequenced ID with optional manual ID, a secondary sequenced ID, or a full primary key coming in with no sequencing.
The update does a few fancy tricks with statuses and will populate an oldStatusId OUT attribute if one is defined in the service def. If a serviceId is coming IN and it is different than the current value then it will also check to see if there is a StatusValidChange record that covers the change, otherwise you'll get an error.
This covers most of what is needed in CrUD operations, and I've done a fair bit of testing, so feel free to start enjoying it and please let me know if you run into any issues, or you can think of other common patterns we can identify based on the service definition and such to cover more existing services then please let me know.
Also, if anyone feels the desire feel free to review existing services that use the common patterns (documented in the org.ofbiz.service.engine.EntityAutoEngine.java file) and get rid of them and just use the engine="entity-auto" attribute.
On a related note: this is something I've debated for or against using for a long time and finally decided that we might as well. Most of the custom additional stuff we want to add to services using these common patterns can be called through SECA rules. Anything we do lots of times, we might as well add to the entity-auto implementation.
My original thought on this is that it would be easier to customize if we had a simple-method for each of these that could be easily changed, and because in spite of requiring additional initial effort the ongoing maintenance would be easier we would see a net reduction in effort because of the pattern.
I'm not so convinced of this now, so here's the new tool...
On another related note: I would like to look for other things that we end up doing over and over and re-evaluate whether or not it is really worth it, or if we should create something like this that covers our common patterns and reduces the amount of code we have to write and maintain.