[
https://issues.apache.org/jira/browse/ISIS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440160#comment-13440160
]
Dan Haywood commented on ISIS-248:
----------------------------------
HERE'S THE DETAIL OF A MAIL I SENT TO isis-dev RELATING TO THIS TICKET.
-- Dan
~~~~~~~~~
Some of the recent commits I've been doing now allow the version information (a
sequence, and an optional user and timestamp) to be stored in the RootOid.
This version information, if present, isn't part of the equals()/hashCode()
equivalence checks, but is serialized out as part of the state. As such, it
constitutes a convenient way for a viewer to capture the version of an object
that has been rendered, just by serializing the Oid. This commits were done
under the general slew of commits under ISIS-14 (the JDO object store), and are
non-breaking.
Concurrently with this, the existing Version interface, as referenced by
ObjectAdapter/PojoAdapter, also holds a sequence, user and date. ISIS-245 was
a ticket I worked on yesterday, which collapsed to Version hierarchy (Version
being an interface, and SerialNumberVersion and FileVersion being the two
implementations) into a single class, called Version. I've retained
SerialNumberVersion and FileVersion, but their only distinguishing
responsibility was to act as a factory (providing defaults for the different
fields of Version).
I then retrofitted the version information within RootOid so that it holds a
reference to Version.
All of the above is just a refactoring, and should be non-breaking.
ISIS-248, finally, was another ticket I worked on yesterday, in which the
version field on ObjectAdapter disappears, and instead the ObjectAdapter
delegates to its Oid for the version information. Any call to set the version
(following an update) on the ObjectAdapter is delegated on similarly.
The new, breaking, change is the following check that's been added in
AdapterManagerDefault (the class that retrieves the object from the datastore):
@Override
public ObjectAdapter adapterFor(final TypedOid typedOid) {
// attempt to locate adapter for the Oid
final ObjectAdapter adapterLookedUpByOid = getAdapterFor(typedOid);
if (adapterLookedUpByOid != null) {
return adapterLookedUpByOid;
}
final Object pojo = pojoRecreator.recreatePojo(typedOid);
ObjectAdapter adapter = mapRecreatedPojo(typedOid, pojo);
// START: ISIS-148 change
Oid adapterOid = adapter.getOid();
if(adapterOid instanceof RootOid) {
final RootOid recreatedOid = (RootOid) adapterOid;
final RootOid originalOid = (RootOid) typedOid;
recreatedOid.checkLock(getAuthenticationSession().getUserName(),
originalOid);
}
// END: ISIS-148 change
return adapter;
}
It ought now to be possible to start removing concurrency checks from the
viewers (Scimpi, HTML etc), while those viewers that don't yet do proper
concurrency checking (Wicket, Restful) will get this for free (but need to
handle any ConcurrencyExceptions that could now propogate out of the persistor.
> Perform concurrency checking within the persistor (rather than rely on every
> viewer/client to do the check)
> -----------------------------------------------------------------------------------------------------------
>
> Key: ISIS-248
> URL: https://issues.apache.org/jira/browse/ISIS-248
> Project: Isis
> Issue Type: Improvement
> Components: Core: Runtime
> Affects Versions: 0.2.0-incubating
> Reporter: Dan Haywood
> Fix For: 0.3.1-incubating
>
>
> Currently it is the responsibility of each viewer to check whether a domain
> object has been updated prior to completing an edit.
> For example, if an object is displayed, the viewer renders the OID (usually
> in the HTML) and also caches the version of the object somewhere (either in
> the HTML, or possibly in a http session). If the user then invokes an
> action, then the viewer resolves the object and checks that the version has
> not changed.
> This ticket is to move this check into the persistor so that, when an object
> is resolved, the version is also supplied. The persistor then throws a
> concurrency check if there is a mismatch.
> The intention is for the API of the Persistor to remain unchanged, accepting
> only an Oid to resolve the object, but to use the version details that can
> now be stored in the Oid (see ISIS-245).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
