Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> Re: [jira] [Commented] (ACCUMULO-227) Improve in memory map counts to provide cell level uniqueness for repeated columns in mutation


Copy link to this message
-
Re: [jira] [Commented] (ACCUMULO-227) Improve in memory map counts to provide cell level uniqueness for repeated columns in mutation
The reason for 'all but one' is to adhere to the concept of a map, and by 'arbitrarily' I mean, whatever way incurs the least processing cost.

On Dec 22, 2011, at 5:09 PM, Keith Turner wrote:

> This still does not address the issue of separate mutations inserting
> the exact same key.  Also timestamps are only set on the keys in a
> mutation if the user does not set them.
>
> So if a table comes to have multiple keys that are exactly the same,
> what do you propose?  That we drop them?  Which one will you drop?
> One nice thing about Accumulo is that if you wish to have this
> behavior, you can very easily write an iterator to do it.  I think you
> are proposing that we configure an iterator to do this by default?
>
> I think if the user is inserting things with exact same key and
> expecting it to behave like a treemap (honor order of arrival), then
> it never will.  Even if we drop duplicate keys, we will not achieve
> the map behavior you described.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB