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 > > ~~~~~~ > >
