gora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lewis John McGibbney (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GORA-385) Check if GORA-270 and GORA-275 should remain or be reverted
Date Wed, 28 Jan 2015 19:58:34 GMT

     [ https://issues.apache.org/jira/browse/GORA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Lewis John McGibbney updated GORA-385:
    Fix Version/s: 0.7

> Check if GORA-270 and GORA-275 should remain or be reverted
> -----------------------------------------------------------
>                 Key: GORA-385
>                 URL: https://issues.apache.org/jira/browse/GORA-385
>             Project: Apache Gora
>          Issue Type: Bug
>            Reporter: Renato Javier MarroquĂ­n Mogrovejo
>             Fix For: 0.7
> For using Gora in a MR job, it needs io.serializations to be set with org.apache.hadoop.io.serializer.WritableSerialization,
org.apache.hadoop.io.serializer.JavaSerialization, and it should be only done once (whether
as part of the cluster configuration, or as part of the job). This means that for a Hadoop
job all Gora-related data will be serialized in a specific manner.
> By accepting GORA-270 and GORA-275,we need to pass this Hadoop configuration with every
single query object, which doesn't make sense as this is a Hadoop configuration and not a
Gora configuration. This led to brake the integration with Giraph, right now a query object
can't be generic, it has to pass the configuration even though this configuration has already
been set for the whole job.
> The configuration object does not contain anything related to Gora and I think that was
the reason why it was static. I think we should revert this, create a test for showing that
we need this, and put it back if needed.
> We should create a test create to confirm GORA-270 and if non can be found, then we should
revert them.

This message was sent by Atlassian JIRA

View raw message