Inline, below.. > > Anyway, to my question: What is the most appropriate method of > > telling the SQL-OS to not automatically load these values? > > > > [snip] > > I guess some kind of domain marker (e.g. an annotation would > > probably be easiest, my preferences notwithstanding) which is picked > > up by either the (Abstract)AutoMapper or the FieldMapping > > implementation.. > > > Yeah. I recently introduced @CommonlyUsed, as an eager-loading hint for > collections (and also, potentially, for references). I chose this names > because I also had the idea that it could apply for actions, to indicate > making them easily accessible in the UI, eg as a button. > > 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. > > but the viewers would still need a way to actually > > force the value to be loaded when it is ultimately required, e.g. to > > upload the document / image to the user.. > > > > > I think this is actually something quite different. The cglib wrappers > (installed by the ObjectFactory) should take care of loading via the > AdapterManager. So I don't think that the viewers need to do anything to > resolve an object. I would need to understand this process a little more, to confirm that, in the SQL-OS, I know where to catch the two hints (none = eager = normal, lazy = only when *really* required). > But the viewers *do* - obviously - need to provide some custom widgets in > order to upload new documents etc. Yes. > > I am not seeing how individual domain/entity properties can indicate > > their "loaded" state. At present the SQL-OS treats the entire entity as > > loaded or not loaded. > > > > In JDO, the enhancement process that runs over the pojos builds a little > data structure whereby the load/resolve state of each attribute is > maintained. To support this more generally, it'll probably be necessary to > use a custom PojoAdapterFactory and create a subclass of PojoAdapter that > holds a map. > > 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. That is probably quite reasonable. I would only really extend the capabilities of the SQL-OS because I wanted the challenge. But there are limits! Using JDO would be a much (safer) long term solution. 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]. > > (This is also linked to a possible extension to the SQL-OS: if the "dirty" > > state of individual properties is known/used, then only those properties > > that have changed could be updated... my real challenge would be to > > detect adding/removing items from collections, and adding/removing > > them individually from the SQL-OS tables, but I digress... ) > > > > I do slightly worry about the SQL-OS becoming this big monster of an ORM. > For prospective users we ought to be clear when it should be used, and > when it shouldn't. Yup. See my previous comment, above. Regards, Kevin [1] http://isis.markmail.org/message/ybqgdjt3er4lljt7
