Hi, Renato. I see. In my oppinion, the changes to the compiler and changes to PersistentBase should be done in that issue. I find the title and description incomplete.
"Removal of _g_dirty field from _ALL_FIELDS array and Field Enum in Persistent classes" implies: 1* Define the method of state management: Before GORA_94 we had StateManager. In GORA_94 it was deleted and introduced as a field (and lost state management of maps, but that is other topic). Now will be pull out again as a state management, but in PersistentBase. It's fine, but I think this should be think about before removing __g__dirty field since here would be defined where would the state management would go and why. 2* Remove the field (done) 3* Implement the state management and update setDirty() implementation. 4* Regenerate examples/generated classes. All seems to be one single commit :) Thanks for your explanation! About GORA-189, I still don't understand why it was throwing a ClassCastException since "get(0)" should be of type byte (=ByteBuffer) :( Regards, Alfonso Nishikawa 2014-08-05 12:41 GMT+02:00 Renato Marroquín Mogrovejo < renatoj.marroq...@gmail.com>: > I will try to :) > So GORA-189 is for fixing/alleviating the problems described there. It > doesn't have to do with the removal of the dirty_bytes array from the data > beans and compiler. > GORA-326 aimed to not to make this field (dirty bytes array) visible by the > users as some users could try modifying/getting it directly. So the patch > posted there now made the dirty bytes array part of Persistent and in that > way all users' data beans don't have to contain this extra field and helps > cleaning the interface up. I was just reviewing my own patch and there are > another couple of things I'd like to fix (not in functionality but > variable's names, getters and setters). Besides that, the dirty bytes array > was only being used inside Gora so the need for the "setDirty" i.e. the > setter was never used inside Gora, maybe now we can make Gora to use a > private setter instead of using the field directly. > Thanks for taking a look into this Alfonso! > > > Renato M. > > > 2014-08-05 11:20 GMT+02:00 Alfonso Nishikawa <alfonso.nishik...@gmail.com > >: > > > Hi, Renato. > > > > I only meant if Lewis applied it to his local copy. > > > > By the way, I am quite disconnected of GORA-326, but surely you can help > me > > :) where is the modified method "setDirty()"? How will be finally the > > management of dirty values? > > > > Thanks! > > > > Alfonso Nishikawa > > > > > > > > 2014-08-05 11:05 GMT+02:00 Renato Marroquín Mogrovejo < > > renatoj.marroq...@gmail.com>: > > > > > Hi Alfonso, > > > > > > The patch in GORA-326 has to be rebased as there are other fixes that > > have > > > come in before this one :( I will try to do that this week, but I > wasn't > > > able to reproduce Lewis' error reported there. > > > GORA-326 aims to make dirty_bytes part of the class hierarchy instead > of > > > copying the array to all classes and data beans. It makes sense that it > > is > > > part of Gora and not of users' data beans. Of course that will lead us > to > > > make other improvements on gora-compiler, but I haven't created any > JIRA > > > regarding that yet because GORA-326 hasn't gone in. > > > > > > > > > Renato M. > > > > > > > > > > > > 2014-08-05 10:45 GMT+02:00 Alfonso Nishikawa < > > alfonso.nishik...@gmail.com > > > >: > > > > > > > Hi! > > > > > > > > I don't understand the fix :S > > > > > > > > getDirtyBytes was: > > > > > > > > private ByteBuffer getDirtyBytes() { > > > > return (ByteBuffer) get(0); > > > > } > > > > > > > > so, it was returning the content of the field __G__DIRTY(0, > > > "__g__dirty"), > > > > defined in the schema as type bytes. > > > > Why exactly is needed to convert to string, etc? > > > > > > > > Have you applied GORA-326 [1] about removal of __g__dirty? (don't > apply > > > it > > > > ;P) > > > > > > > > @Lewis: Can you send us you the java code of that class you talk > about? > > > The > > > > generated class that has the "previewText" field. > > > > > > > > Thanks!! And so sorry for answering so late :( > > > > > > > > Alfonso Nishikawa > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/GORA-326 > > > > > > > > > > > > > > > > > > > > > > > > 2014-07-29 23:39 GMT+02:00 Henry Saputra <henry.sapu...@gmail.com>: > > > > > > > > > I haven't had to use the Union support so that is probably why > never > > > > > this seen this issue. > > > > > > > > > > On Tue, Jul 29, 2014 at 1:57 PM, Lewis John Mcgibbney > > > > > <lewis.mcgibb...@gmail.com> wrote: > > > > > > Hi Folks, > > > > > > Right now, one defines a field as follows > > > > > > > > > > > > {"name": "previewText", "type": ["null","string"], > "default":null} > > > > > > > > > > > > and we generate this object using the current > > > > gora-compiler-0.5-SNAPSHOT, > > > > > > then if I populate this object with either Utf8 or String then I > > get > > > > > > ClassCastException when I attempt to cast the dirty value to > > > ByteBuffer > > > > > > within PersistentBase as follows [0]. > > > > > > > > > > > > private ByteBuffer getDirtyBytes() { > > > > > > return (ByteBuffer) get(0); > > > > > > } > > > > > > > > > > > > To be honest with you, the method looks rather adhoc where it is > > > within > > > > > the > > > > > > class. Maybe that is only my opinion however I think that this > is a > > > > > bug... > > > > > > or more appropriately, we could improve upon the method which > would > > > > > > certainly leave less owness to the developer to somehow 'know' > that > > > we > > > > > are > > > > > > going to cast to ByteBuffer later on. > > > > > > > > > > > > For example I found Alfonso's issue from a while ago [1] which > > > > > essentially > > > > > > describes the same thing e.g. where more flexibility should be > > > > > encapsulated > > > > > > so that an extended variety of text-based representations can be > > > > > populated > > > > > > into CharSequence field values. > > > > > > > > > > > > Does anyone have a comment on this one? I am really surprised > that > > > I've > > > > > > only just expreienced this... in my case I am passing in a String > > > with > > > > > the > > > > > > call to .setPreviewText(CharSequence char)... this results in > > > > > > ClassCastException as described in [1]. > > > > > > > > > > > > Thanks > > > > > > Lewis > > > > > > > > > > > > [0] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/gora/blob/master/gora-core/src/main/java/org/apache/gora/persistency/impl/PersistentBase.java#L175 > > > > > > [1] https://issues.apache.org/jira/browse/GORA-189 > > > > > > > > > > > > > > > > > > -- > > > > > > *Lewis* > > > > > > > > > > > > > > >