Hi Damien, On Tue, May 20, 2014 at 6:38 AM, Damien Raude-Morvan <draz...@drazzib.com>wrote:
> > It seems that PersistentDatumReader and PersistentDatumReaderWriter are > now gone in master branch. As I've find in git log, they have been dropped > in GORA-321 (GORA_94 branch merge to master). > Yep, this was during the redesign of the Persistency API. Actually, more accurately, the code was deleted but the empty class files were mistakenly retained during the merge of GORA_94 branch in to trunk... I've removed the empty files as of commit e8e58a42564621274ae4737ce3f07cebb9935b07 Generally speaking the improvements in both Avro functionality and API design meant that extending them (where possible) made more sense. So on top of the redesign of Persistent to remove States e.g. NEW< CLEAN< DIRTY< DELETED managed by StateManager, Ed also suggested to remove the writing of transient information (the dirtyness) from being a hack on top of Avro. This was necessary since the Avro encoder system is now packaged up in such a way that you really can't override ResolvingDecoder, which was necessary for the previous implementation. Ed did this by doing a total rework of the Gora compiler so that it extends AvroCompiler. This also makes this class more manageable because the 1.7 Avro compiler uses velocity templates and has become fairly extendable. The new scheme for tracking dirtyness is to augment each schema with a new field, _*g*_dirty, which keeps track of what fields are dirty. Has also made work on making dirty more reliable. Using Utf8 classes and ByteBuffers, it is possible to make a field dirty without the set() method for the field intercepting the mutation. Structural changes to records, maps, lists, and unions are tracked automatically, however, as are changes on immutable types such as numbers and booleans. N.B. the above is mostly taken from GORA_94 commentary... which is very helpful. > > Those classes were really useful to me to serialize Gora persistent > objects with all their dirty information (for instance to send them over > the wire on AMQP). > As suggested by Henry, why does the new API not permit you to do what you request? You should be able to access ALL of the stuff you previously did as we extend Avro functionality natively now instead of the hack which we had on top... you should also be able to leverage some other functionality via AvroUtils... which has been bulked out somewhat IIRC. > > Is there issues with those classes and Avro 1.7.x ? Is there a way to > restore this feature ? > > If you feel that there are fundamental issues which prevent you from achieving access to dirty object information (I don't see how this can be the case but maybe I am wrong. I am keen to find out) then please comment and we can make best efforts to work towards a solution. The Avro upgrade (as you know) touched many parts of the codebase... it was in every sense of the word, major. Thanks Lewis
