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