gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renato Marroquín Mogrovejo <renatoj.marroq...@gmail.com>
Subject Re: Populating text fields within Gora data beans
Date Tue, 05 Aug 2014 11:10:13 GMT
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 <alfonso.nishikawa@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
> > > > > > <lewis.mcgibbney@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*
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message