incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <...@haywood-associates.co.uk>
Subject Re: More on the Oid refactor
Date Mon, 07 May 2012 17:40:01 GMT
On Saturday, 5 May 2012, Kevin Meyer - KMZ wrote:

> Hi Dan,
>
> For my part, I can't really see any problems, and I'm just hoping that
> my apps will continue to work without refactoring when you're done! :)
>
> I've introduced the OidMarshaller with the view that this could be
pluggable (though I'm not quite sure where that plug-in point is, yet!).
 So, there could be a LegacyOidMarshaller that knows how to read existing
serialized OIDs, but when saving again would persist to the new format.  A
sort of "upgrade-in-place" approach.




> I realise that my Cayenne OS will take a hit, but ID's are problem for
> me there anyway, as I still have problems managing ID's between the
> Cayenne back-end and the Isis back-end. Each thinks they "own" the
> IDs, and each has their own table to hold next ID.
>

Previously this was the responsibility of the OidGenerator component.  In
fact, prior to the refactoring this had two responsibilities: to
instantiate the appropriate Oid implementation specific to the object
store, and to generate unique identifiers.

In the refactoring, since the Oid implementations are always fixed
(RootOidDefault, AggregatedOid), I've broken this component into two: the
bit that does the instantiation is no longer pluggable, but the bit that is
pluggable is an IdentifierGenerator that creates the instanceId (for
RootOidDefault) or localId (for AggregatedOid).  What this new
IdentifierGenerator interface now has is that it accepts the pojo that is
being instantiated.  The idea is to allow the object store to reflectively
inspect the object after its been persisted, to allow the value to be
sync'ed.



>
> Another comment: as for "stringifying" the IDs, I assume you're only
> talking about the OIDs themselves. For the SQL-OS I've been trying to
> ensure that there is a "string-free" path when-ever possible - meaning
> that my "to table" and "from table" methods work with binary objects as
> much as possible.
>



>
> For the IDs, this generally means that I need a method of mapping the
> ID to/from long (the database table default).
>

Hmm, well...  I can understand why you might want to use longs etc in the
SQL-OS, eg for performance reasons, but I'm trying to make OID a little
more generic than that, ie usable in URLs, HTML pages, JSON and XML docs
etc.

The way I see this working is that the SqlOsIdentifierGenerator impl might
always generate long's, but this would be converted into strings for OIDs.
 Going the other way, the SQL OS could safely parse out the long from the
OID whenever necessary, eg Long.parseLong(oid.getIdentifier()).  Agreed,
this adds a little overhead, but it gets us a lot more flexibility and
should let us simplify in lots of places.





>
> I don't know if this affects anything on your side.
>

Either 0.3.0-incubating will be a breaking release, or we can do the work
to add in the "upgrade-in-place" stuff with an OidMarshaller if we find
lots of users who have deployed apps and require this capability.  It'll be
interesting to see if we get any new voices objecting to us putting out a
breaking release.

Dan



>
> Regards,
> Kevin
>
> On 5 May 2012 at 10:13, Dan Haywood wrote:
>
> > Hello all,
> >
> > First, just to say that I *know* the build is broken, and it's a pretty
> > poor show on my part to let it happen, but it's a little bit of breaking
> > eggs to make an omelette.
> >
> ...
> > OK, that's it for now.  Wanted to put this out there for reaction; as
> usual
> > with these things, I'll assume silence = consensus.
> >
> > Dan
> > ~~~~~~
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message