Hi,
I had not tried the patch, just took my attention since I had been taking a
look at Persistent* after GORA_94.
By this time I am stick to early Gora-0.4-SNAPSHOT developing the
connectors for Pig and Cascading. The changes of GORA_94 were quite huge
(some semantics in dirty management changed)
Hi Alfonso,
On Tue, Aug 5, 2014 at 1:47 AM, wrote:
>
> I don't understand the fix :S
>
> The fix converts everything to ByteArray and not just simply casting the
value to ByteBuffer... which is illegal.
> getDirtyBytes was:
>
> private ByteBuffer getDirtyBytes() {
> return (ByteBuffer) ge
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 Persiste
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 m
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/
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 R
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
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 y
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
wrote:
> Hi Folks,
> Right now, one defines a field as follows
>
> {"name": "previewText", "type": ["null","string"], "default":null}
>
> and we generat
Hi Folks,
I've posted a trivial patch for this to GORA-189.
https://issues.apache.org/jira/browse/GORA-189
I would really appreciate if someone could review.
It passes all tests.
Thanks
Lewis
On Tue, Jul 29, 2014 at 4:57 PM, Lewis John Mcgibbney <
lewis.mcgibb...@gmail.com> wrote:
> Hi Folks,
>
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 t
11 matches
Mail list logo
