On 21 September 2012 09:37, Kevin Meyer - KMZ <[email protected]> wrote:
> > > > But perhaps it was a mistake. Maybe it should just be called > > @ResolveHint(EAGER) or @ResolveHint(LAZY), so that, with a single > > annotation, support: > > - eager loading of references and collections (by default, are loaded > > lazily) > > - lazy loading of values (by default, are loaded eagerly) > > > > Then, the ResolveHintFacet could be inferred from the type, > > [snip] > > Right.. renaming your hint could be used for both cases, as listed. > > In which case, I'm gonna just go ahead and do that rename. I'm currently constructing a reply per Giedrius' work (elsewhere on this thread), and it would fit in with his work to date too, I think. [snip] > > > > However, I'm not that keen on doing that; I'd rather keep aiming to > > simplify the codebase, rather than make it more complex. I'd rather that > > the SQL-OS is positioned as the "baby brother" of the JDO-OS, easier to > get > > going, but with more limited capabilities. Once a developer hits its > > limits, then they can move to JDO. > > [snip] > > Perhaps my energies could be better spent on helping JDO > "understand" Isis, so that JDO-specific annotations become less > required. I believe this was hinted at previously [1]. > > Hmm, other way around. That is, use JDO annotations rather than Isis, where it makes sense. The reason being that the JDO community is larger than the Isis community, and JDO is after all a fully-fledged standard. So we should conform to it rather than trying to go the other way. Basically, though, all we're talking about is some new FacetFactory's that understand JDO annotations and install them appropriately for Isis to interpret. ~~~ If you are interested in looking at JDO a little more, then one thing you could explore is how well it works using the metadata in .jdo / XML metadata files. I suspect that JDO will "just work", but of course any of our equivalent FacetFactory's would need to know to look for this JDO metadata. And, thinking this through a little bit more, it occurs to me that these FacetFactory's should really be having the JDO metamodel injected into them and reaching into it. Otherwise, we'd need to write FacetFactory's that interpret and parse the .jdo/XML metadata files, which doesn't sound like an awful lot of fun. Dan
