[jira] [Updated] (GORA-138) gora-cassandra array type support
[ https://issues.apache.org/jira/browse/GORA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kazuomi Kashii updated GORA-138: Attachment: GORA-138-v2.patch Since all related patches (GORA-131, 132, 133, 134, and 139) have been applied to trunk, I created a new patch for GORA-138. Also, I have cleaned up duplicated code in gora-cassandra. gora-cassandra array type support -- Key: GORA-138 URL: https://issues.apache.org/jira/browse/GORA-138 Project: Apache Gora Issue Type: New Feature Components: storage-cassandra Affects Versions: 0.2 Reporter: Kazuomi Kashii Fix For: 0.3 Attachments: GORA-131-132-133-134.patch, GORA-138-v2.patch, GORA-138.patch In order to support ARRAY in gora-cassandra, we have two scenarios as follows: 1) super column family like the current MAP implementation; or 2) single column to store all elements of ARRAY. Each senario has pros and cons, but I'd prefer 1) and I have implemented a prototype. 1) super column family ** pros - consistent with MAP - each column stores primitive type value. ** cons - ARRAY cannot be contained in RECORD or MAP. 2) single column ** pros - complex type such as RECORD and MAP can have ARRAY value. ** cons - large size of ARRAY requres a huge single column value. - difficult to implement for STRING and BYTES (variable length). Currently, super column is used for other complex types such as RECORD and MAP, so it is consistent to use super column for ARRAY. Considering this, the rule that complex type cannot have complex type value seems a reasonable limitation, and it makes rule simple. If we take 1) senario with super column family, I can provide a patch of my implementation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (GORA-140) Requires some adjustments on dependency at gora-cassandra
Kazuomi Kashii created GORA-140: --- Summary: Requires some adjustments on dependency at gora-cassandra Key: GORA-140 URL: https://issues.apache.org/jira/browse/GORA-140 Project: Apache Gora Issue Type: Improvement Reporter: Kazuomi Kashii Priority: Minor avro and slf4j-log4j should be added. cassandra-all can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GORA-140) Requires some adjustments on dependency at gora-cassandra
[ https://issues.apache.org/jira/browse/GORA-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13281033#comment-13281033 ] Lewis John McGibbney commented on GORA-140: --- Hi Kazuomi. Did you experience any problems when upgrading the main pom.xml to point to Cassandra and Cassandra thrist to 1.1.0, and hector 1.0-4 respectively? I opened GORA-124 to track and implement the upgrade to Cassandra v1.1 but if simply changing the main pom works then thats great. I will be able to test later on. Thank you Requires some adjustments on dependency at gora-cassandra - Key: GORA-140 URL: https://issues.apache.org/jira/browse/GORA-140 Project: Apache Gora Issue Type: Improvement Reporter: Kazuomi Kashii Priority: Minor Attachments: GORA-140.patch avro and slf4j-log4j should be added. cassandra-all can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (GORA-140) Requires some adjustments on dependency at gora-cassandra
[ https://issues.apache.org/jira/browse/GORA-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13281054#comment-13281054 ] Kazuomi Kashii commented on GORA-140: - I have been using Cassandra 1.1.0 with Gora or other applications for a while, and most of client libraries such as Hector and Pelops for Cassandra 1.0.x seem compatible without any modification. In my understanding, there is no change on Thrift layer between Cassandra 1.1 and 1.0.x. Requires some adjustments on dependency at gora-cassandra - Key: GORA-140 URL: https://issues.apache.org/jira/browse/GORA-140 Project: Apache Gora Issue Type: Improvement Reporter: Kazuomi Kashii Priority: Minor Attachments: GORA-140.patch avro and slf4j-log4j should be added. cassandra-all can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
StateManager
Hi, As part of my work on GORA-94 I am contemplating removing or refactoring the StateManager interface and corresponding (sole) implementation, StateManagerImpl. What is the use case for this class? It seems like it unnecessarily complicates the implementation of persistent objects, and if people aren't aware of what it does they might easily implement a persistent object incorrectly by keeping two inconsistent state definitions. In my opinion it also broadly breaks the OO principle of encapsulation. I'd suggest one of two strategies - remove it, making the persistent object itself the sole representation and source for its readable and dirty state, or refactor persistent and remove the methods that represent its dirty and readable state. It might make sense to turn it into an inspector object like those used in HIVE's serde system. I think the simplest solution is to remove it, but I could be missing something. Thoughts?
