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 09:05:37 GMT
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