On 18 September 2012 18:37, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> 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, perhaps as an
additional responsibility of ValueSemanticsProvider. Thus, we could state
in a single location that a blob-type thing should be lazily loaded by
default, eg:
@Value(semanticProvider=....)
public class MyBlob { ... }
Incidentally, JDO has the concept of fetch groups, which kinda work this
way. So in my JDO object store I'd also probably translate these fetch
group annotations into Isis-equivalent ResolveHintFacets for the benefit of
the viewers.
> 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.
But the viewers *do* - obviously - need to provide some custom widgets in
order to upload new documents etc.
By way of comparison, NO MVC (on .NET) uses a FileAttachment class, which,
basically, is a blob. Any property or parameter of this type can be
specified using a file dialog in the browser. But this is all just a UI
concern for getting a bunch of bytes; it has nothing to do with resolving
the entity that ultimately holds those bytes.
> 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.
> (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.
Dan
