Marc Morin wrote: > We chose to use the full model reader when running the > entity-gen since there are not trivial manipulations of the > en*xml files, such as extending, auto-relationships, > auto-indexes, materialized views, view optimizations... > > We don't entiy-gen on every build. Manually done. This is a > bit of a pain, would be better if it was performed when needed.
So, I have a stylesheet that does most of plain entity->java. Handles getRelated stuff(returning specific values, not GenericValue), and static findOne/findList in each class. This was mostly straight forward to do. It also handles view alias-all, alias, including nested views. Complex aliases, and extend-entity/relations aren't yet handled(neither are overly complex to add to the xslt). However, GenericPK/GenericValue use javolution object pools. If there is a separate class for each entity, the number of object pools grows quite a bit. Additionally, the instances stored in each pool can no longer be shared(ie, a Party class instance can't be pooled with a Person class instance; previously, they'd both be a GenericValue, so might get recycled together). Then, there is the requirement that javac needs to stay around on production. The entity classes must be generated close to a production deployment; precompiling just the standard models in ofbiz won't help, as end-user deployments will add new entities and/or extend existing ones. This modification could even be done on the production instance itself. So, I'm still torn on whether this is such a good idea. I have no problem at all with a tool like this being available in ofbiz, and being used by end-user installs, but there are just too many issues that I see with using it by default in normal ofbiz code.
