On 8 September 2013 11:55, Kevin Meyer - KMZ <[email protected]> wrote:
> > I must admit that was one of our expectations when we firstly > > approximated Isis, perhaps because we were following the email list > > or saw the SQL Objectstore, etc. > > > > In fact, seems that recently we have taken the opposite path (by > > requiring nearly all Entity properties to be annotated with > > @Column(allowsNull="true|false"), instead of improving the JDO > > Object Store usage of the Isis meta-model. > > When I first started with Isis (when it was still Naked Objects), I was > really drawn to the fact that any POJO that I prototyped could be > re-used "as is" elsewhere, as it contained no "framework" clutter. > > As Oscar says, this is now exactly the opposite. If the assumption is > that Isis will always be the deployment framework, this is just fine! > > > But we cannot expected to map/solve all ORM requirements on the Isis > > metamodel, so the end situation will be some inferred, some > > explicited for sure. > > In the SQL OS, I provided for "hints" to be specified in the properties > file (overriding property-field mappings, table naming, etc) (and > Eclipse could handle refactoring/renaming if the full name name was > used in the properties file) - leaving the POJO clean of DB clutter. > > Yes, it's true that we now have the Isis metadata as secondary to the JDO annotations. This breaks symmetry and means that, to deploy Isis against a different ObjectStore, that at best those JDO annotations are redundant, at worst one that one would have put in equivalent metadata for the other OS (eg SQL OS' properties). As mentioned, we could invert this. Using the DataNucleus metadata API [1], we could programmatically build up the DataNucleus metamodel from the Isis metamodel. Where required, we could also recognize some subset of the JDO annotations that have no Isis equivalent (eg "mappedBy" for bidirectional annotations). Or, I suppose, we could add in our own equivalent Isis annotations. I'm not convinced that this is the right thing to do though, for two reasons: 1. there are many potential users out there that understand JDO (and JPA, of course, when we get around to support it's annotations). Requiring them to learn the Isis equivalents is going to put them off. 2. I don't think that being able to switch between object stores is that significant. While presentation/UIs are fashion items that change every few years, the data in a production database tends to stay where it is. Indeed, the application/domain model itself is more volatile than the data; right now over in Ireland we are building a replacement naked objects app to the original, against the same physical DB schema, but with a changed domain model in certain cases. Putting my cards on the table, I would rather that Isis leverage DataNucleus for handling different persistence mechanisms through DN's own StoreManager API [2]. Using Oscar's terminology, DN's goal is to provide the ports and adapters (of the hexagonal architecture) for persistence, while Isis handles the the ports and adapters everything else (presentation/UI in particular). What I also want to do, long term, is to deprecate all the other Isis object stores and eventually remove them. We could then start to simplify Isis internally. Obviously, this is for the community to decide on this, but it's where I currently stand. It's worth noting that on Naked Objects.NET, they are following an equivalent path, where they just use an ObjectStore based on Microsoft's Entity Framework. In fact, they are going further: where there is an EF metadata annotation, they are deprecating their NO-specific one. They have also already dumped all their other object stores bar their in-memory object store. Thx Dan [1] http://www.datanucleus.org/products/datanucleus/jdo/metadata_api.html [2] http://www.datanucleus.org/extensions/store_manager.html
