i second UUID they're your friend On Sat, Feb 28, 2015 at 10:56 AM, Brian Sam-Bodden <bsbod...@integrallis.com > wrote:
> I agree with Peter. I typically keep in Cassandra just the data that will > benefit from it's distribution and replication capabilities. Most of the > applications in which I use Cassandra also use a relational DB, so best > tool for the job type of approach. > > And for the PK it's implied; some identifiers are temporal, some others > are not, PK should use non-temporal ones, e.g. phones and addresses are a > bad idea, SSNs might be ok but in general for C* synthetic PK are best, > e.g. UUIDs or TimeUUIDs. > > On Sat, Feb 28, 2015 at 8:42 AM, Peter Lin <wool...@gmail.com> wrote: > >> >> Hate to be the one to point this out, but that is not the ideal use case >> for Cassandra. >> >> If you really want to brute force it and "make it fit" cassandra, the >> easiest way is to create a class called Index. The index class would have >> name, phone and address fields. The hashcode and equals method would need >> to be overrided. Basically the same rules that apply to HashMap keys. Once >> you have that, you can use "if not exists" in the insert. >> >> Here's the risk though. What happens when the phone and address changes? >> The hashcode and equals will fail and queries will fail. This is a general >> anti-pattern for anything that uses Maps and is mutable. This is the reason >> the default object hashCode in java is system assigned and there's all >> sorts of warnings about overriding hashCode and equals. >> >> The only case where this works correctly is immutable databases or >> temporal databases. I would strongly advise against using a key that is a >> compound of name+phone+address. If the system needs to perform updates, the >> key needs to be immutable so that queries won't fail. >> >> On Sat, Feb 28, 2015 at 10:18 AM, Brian Sam-Bodden < >> bsbod...@integrallis.com> wrote: >> >>> As far as I know there is no such thing. You could make that value a >>> single PK for the table therefore guaranteeing uniqueness and check on >>> insert with `IF NOT EXISTS` to prevent dups. Of course that works just for >>> one value, if you have multiple values a compound PK will still let dups in >>> for a given column. So a different data model might be the answer there. If >>> the values in those columns can be enumerated then you could always create >>> a bitmask for the collection of values of the must-be-unique columns and >>> use that as park of your PK. If they ranges are too broad then maybe some >>> sort of hash made up of the values that need to be unique would be my next >>> attempt. >>> >>> You could also simply enforce the uniqueness programmatically but that >>> will require a read-before-you-write approach. Three is also the >>> possibility of using a Cassandra trigger (but I heard they are dangerous >>> and might not buy you anything more than the client-side programmatic >>> approach) >>> >>> Cheers, >>> Brian >>> http://integrallis.com >>> >>> On Fri, Feb 27, 2015 at 9:29 PM, ROBIN SRIVASTAVA < >>> srivastava.robi...@gmail.com> wrote: >>> >>>> I want to make unique constraint in Cassandra . As i want that all the >>>> value in my column be unique in my column family >>>> >>>> example : name-rahul ,phone-123, address-abc >>>> >>>> now i want that in this row no values equal to rahul ,123 and abc get >>>> inserted again on searching on datastax i found that i can achieve it by >>>> doing query on partition key as IF NOT EXIST ,but not getting the solution >>>> for getting all the three values unique means if >>>> >>>> name- jacob ,phone-123 ,address-qwe >>>> >>>> this should also be not inserted into my database as my phone column >>>> has the same value as i have shown with name-rahul. >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Brian >>> http://www.integrallis.com >>> >> >> > > > -- > Cheers, > Brian > http://www.integrallis.com >
