Thanks for al the responses regarding JDO vs SQL. However, my project moved in a direction where the model is not known at compile time. So we need a solution capable of handling the model at runtime. I am not sure if there still is a place for Isis in this scenario.
Currently I am thinking about modelling the domain in OWL and store the data in a RDF database. Metawidget comes to mind for constructing a Gui at runtime. Regards, Minto Op 6-9-2012 20:58, Matthew Adams schreef: > If you didn't like the JDO annotations in your source, you have one other > option I can think of besides the xml metadata option. > > NB: I think it's a pretty heavyweight solution for just a metadata > location preference. > > You could also use AspectJ to introduce the annotations orthogonally. They > would be there at runtime, but you wouldn't see them in source. It would > take some changes to your build environment (I recommend just replacing > javac with ajc), but you need to make sure that if you use AspectJ, do it > before enhancing. > > Note that today, I'd say the best practice in JDO is to use annotations for > logical metadata (like @PersistenceCapable -- those things that don't > change as a function of your datastore type or vendor) and XML metadata for > physical metadata (like OR mappings or other metadata that does change as a > function of your datastore type & vendor). It's a fact of life that > writing persistent objects is different than writing transient ones... > > Perhaps the Isis team could provide aspects or similar functionality that > introduce the appropriate JDO metadata (annotations and/or XML) based on > its own metadata. > > -matthew > > On Thu, Sep 6, 2012 at 12:31 PM, Dan Haywood > <[email protected]>wrote: > >> Jeroen and I talked were also talking about this (he and I are using the >> JDO object store in anger on a project we're working on together). I do >> suspect that it would be possible to "teach" DataNucleus (the underlying >> JDO implementation) about some of Isis' annotations and conventions, thus >> reducing the amount of stuff. >> >> However, we both decided that would be a bad idea. After all, the JDO >> community is that much larger (Google app engine, for example) and more >> established than our own. And hopefully some of those users will come >> across Isis and see its support for JDO, and think about trying it out. It >> wouldn't be a good experience if they have to unlearn hard-learnt JDO >> annotations/conventions and try to figure out how Isis interacts with JDO. >> >> On the other hand, if there are semantics that we can infer into Isis from >> JDO annotations, then that direction is just fine. For example, >> @javax.jdo.Embedded annotation is basically the same as the Isis >> @Aggregated annotation, and so we infer the AggregatedFact from it. >> >> Dan >> >> On 6 September 2012 18:18, Kevin Meyer - KMZ <[email protected]> wrote: >> >>> Now you know why I like the sql-os so much! No annotations, just a >>> few occaisional overrides in the properties file.. >>> >>> I'm slowly reconstrucing my build enviroment (I have recently moved >>> into temporary accommodation).. should able to make some progress >>> soon. >>> >>> Regards, >>> Kevin >>> >>> On 6 Sep 2012 at 14:07, [email protected] wrote: >>> >>>> Do I really have to place all those JDO annotations in my model ? :( >>>> >>>> Regards, >>>> >>>> Minto >>>> >>>> Quoting Dan Haywood <[email protected]>: >>>> >>>>> Yes, it's on the Todo list to provide some docs. >>>>> The quickstart app is configured for JDO, though, so you could stay >>> there. >>>>> >>>>> More detail later today. >>>>> Dan >>>>> >>> >>> >> > > > -- ir. ing. Minto van der Sluis Software innovator / renovator Xup BV Mobiel: +31 (0) 626 014541
