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