> 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(allowsTrue="true|false"), instead of improving the JDO > Object Store usage of the Isis meta-model.
I assume this a typo and you meant "@Column(allowsNull ...)".. 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. BTW: I certainly don't want to suggest that Isis should use manually maintained xml files! Although, if memory serves, Apache Cayenne [1] has a modelling tool (Cayenne Modeler) to manage generating the schema data. Again, I'm not suggesting this as a recommended tool for Isis. Oscar, thanks for reproducing the cited text. It neatly highlights the "edges" and the ease & associate problems with responsibility leakage. Regards, Kevin [1] http://cayenne.apache.org/
