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 < [email protected]>: > 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 <[email protected] > >: > > > 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 <[email protected]>: > > > > > 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 > > > <[email protected]> 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* > > > > > >
