You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@gora.apache.org by Alfonso Nishikawa <al...@gmail.com> on 2014/08/05 10:45:55 UTC
Re: Populating text fields within Gora data beans
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 <he...@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
> <le...@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*
>
Re: Populating text fields within Gora data beans
Posted by Renato Marroquín Mogrovejo <re...@gmail.com>.
Thanks for the input Alfonso!
Yeah you are right about the title, but I just didn't want to make an issue
that was too big, but I will try to put everything and see if it is too big
or not and then we can all decide that to do with it :)
1. __g__dirty will still exist as a field but at the Persistent level, as
this field is shared across all data beans. It makes sense to put it in
their parent class.
We wouldn't have to worry about 2. and 3.
And 4 would be just running the compiler.
About the class cast exception, sorry that was Lewis' problem a few weeks
ago.
Renato M.
2014-08-05 13:00 GMT+02:00 Alfonso Nishikawa <al...@gmail.com>:
> 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.marroquin@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.nishikawa@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.marroquin@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.nishikawa@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.saputra@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
> > > > > > <le...@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*
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Populating text fields within Gora data beans
Posted by Alfonso Nishikawa <al...@gmail.com>.
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.marroquin@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.nishikawa@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.marroquin@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.nishikawa@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 <he...@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
> > > > > <le...@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*
> > > > >
> > > >
> > >
> >
>
Re: Populating text fields within Gora data beans
Posted by Renato Marroquín Mogrovejo <re...@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 <al...@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.marroquin@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.nishikawa@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 <he...@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
> > > > <le...@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*
> > > >
> > >
> >
>
Re: Populating text fields within Gora data beans
Posted by Alfonso Nishikawa <al...@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.marroquin@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.nishikawa@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 <he...@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
> > > <le...@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*
> > >
> >
>
Re: Populating text fields within Gora data beans
Posted by Renato Marroquín Mogrovejo <re...@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 <al...@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 <he...@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
> > <le...@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*
> >
>