In other words - this isn't really a Database Concern is it?
The Database doesn't care if these fields are unique - only your
application and in certain cases?
If your app needs certain cases as unique - create a method to update
a Unique Doc... that stores all unique ID's already used, or
It's very frightful for me implement uniqueness in this way
create doc for each uniq field and keep it in actual state when i update docs.
may be better check uniqueness only in application layer?
now i don't think about distribute.
2010/3/28 Jan Lehnardt j...@apache.org:
You need to have two
On Tue, Mar 30, 2010 at 9:13 AM, faust faust...@gmail.com wrote:
It's very frightful for me implement uniqueness in this way
create doc for each uniq field and keep it in actual state when i update docs.
may be better check uniqueness only in application layer?
now i don't think about
Yes its only one way.
Why couch don't implement uniqueness in simple way?
2010/3/30 Andrew Melo andrew.m...@gmail.com:
On Tue, Mar 30, 2010 at 9:13 AM, faust faust...@gmail.com wrote:
It's very frightful for me implement uniqueness in this way
create doc for each uniq field and keep it in
On Tue, Mar 30, 2010 at 9:44 AM, faust faust...@gmail.com wrote:
Yes its only one way.
Why couch don't implement uniqueness in simple way?
It does implement it in a simple way. You get a unique field. Couch
makes sure that only one document has that field at a same time.
Actually, I was
Document ID's _must_ be a simple string. It would be nice though, to have
complex ID's just as we can have complex keys for our views.
On Tuesday 30 March 2010 16:49:06 Andrew Melo wrote:
On Tue, Mar 30, 2010 at 9:44 AM, faust faust...@gmail.com wrote:
Yes its only one way.
Why couch
Hi,
Actually, I was just thinking, and someone else can correct me if I'm
wrong, but you may be able to do ['email','username'] as the _id.
Even if you can't you can hash/concatenate the two to make a unique
string. You could then store the two fields in the doc (for easy
access in views)
I use a canonical sha1 hash of a JSON object within the doc as the _id to
ensure uniqueness in my app.
FB
On Tue, Mar 30, 2010 at 11:05 AM, Markus Jelsma mar...@buyways.nl wrote:
Document ID's _must_ be a simple string. It would be nice though, to have
complex ID's just as we can have
Perhaps i sent the e-mail a bit too fast because issues would surface if couch
allows complex ID's.
For example, would the entire value of the key be considered to be unique, or
would the individual elements? And what about the order of the values inside
the key?
[user_1, email_1] vs.
but that would not ensure uniqueness in some scenario's:
sha1(email_X + user_X) != sha1(email_X + user_Y)
using, separate documents is currently the only feasible method to ensure this
kind of uniqueness.
On Tuesday 30 March 2010 17:14:27 Freddy Bowen wrote:
I use a canonical sha1 hash of a
Yes, exactly. In my app that's desirable. I missed faust451's specific
use-case.
FB
On Tue, Mar 30, 2010 at 11:18 AM, Markus Jelsma mar...@buyways.nl wrote:
but that would not ensure uniqueness in some scenario's:
sha1(email_X + user_X) != sha1(email_X + user_Y)
using, separate documents
On 30.03.2010, at 20:49, Andrew Melo wrote:
On Tue, Mar 30, 2010 at 9:44 AM, faust faust...@gmail.com wrote:
Yes its only one way.
Why couch don't implement uniqueness in simple way?
It does implement it in a simple way. You get a unique field. Couch
makes sure that only one document
Distributed uniqueness is a hard problem, but since you intend to use it
only on a single node, perhaps you should create a view for each set of
fields that you intend to be unique in your documents.You would emit the
unique combination of values as the key and the document id as the value.
For
To nitpick slightly - you won't get a value of zero, you'll just find that
there is no entry for the given key. ;-)
-Patrick
On 30/03/2010 3:06 AM, Daniel Itaboraí itabora...@gmail.com wrote:
Distributed uniqueness is a hard problem, but since you intend to use it
only on a single node, perhaps
The only solution to enforce uniqueness on a field is using the _id field of a
document. If you need two fields to be unique in a database, you'll need to use
two documents for that.
In addition, in the distributed case, the only way to ensure uniqueness is
eventually, after replication,
Its sounds like pair of crutches ;)
2010/3/28 Jan Lehnardt j...@apache.org:
The only solution to enforce uniqueness on a field is using the _id field of
a document. If you need two fields to be unique in a database, you'll need to
use two documents for that.
In addition, in the distributed
On 28.03.2010, at 14:40, faust wrote:
Its sounds like pair of crutches ;)
Agree with you. Lack of uniqueness, lack of transactions makes couch completely
useless for most cases. Solutions like multiple docs with _id as unique key,
along with inventory tickets sounds insane.
I invented
I am wondering why not introduce locking in couchdb
It's because locking doesn't scale. The locking strategy you outlined
works fine when your database runs on one machine, but fails when it
runs on two or more machines. A distributed lock, while possible,
would require all machines to lock,
Not every document requires locking. Also, not every application requires to be
extremely distributed. Developers can make a decision what kind of application
is cooking, in other words, should it scale to thousands of nodes, or just
single master with many readers would pretty good.
The same
not every application requires to be extremely distributed -- for
everything else, there's CouchDB. :)
I completely agree that not every application needs to be distributed.
For applications that are relational in shape, it makes sense to use a
relational database solution. Conversely, for
If you need multi-document transactions, multiple constraints and
don't need to be distributed, don't need to shard, and don't need
offline replication, it's not clear that CouchDB is a good fit.
I want use Couch for Web App Media portal
is couch good for me
i don`t need to be distributed,
On Mar 28, 2010, at 8:30 AM, faust wrote:
If you need multi-document transactions, multiple constraints and
don't need to be distributed, don't need to shard, and don't need
offline replication, it's not clear that CouchDB is a good fit.
I want use Couch for Web App Media portal
is
On 28 Mar 2010, at 06:03, Alexander Uvarov wrote:
Not every document requires locking. Also, not every application requires to
be extremely distributed. Developers can make a decision what kind of
application is cooking, in other words, should it scale to thousands of
nodes, or just
Hi
In what way i cat implement validation of uniqueness?
User
email: unique
login: unique
Thanks!
On Mar 27, 2010, at 4:56 PM, faust wrote:
Hi
In what way i cat implement validation of uniqueness?
User
email: unique
login: unique
You can only have 1 unique field per database. you implement it by using it as
a docid, like
{
_id : user:unique,
...
}
Chris
but what if i have two unique fields
login
email
2010/3/28 J Chris Anderson jch...@gmail.com:
On Mar 27, 2010, at 4:56 PM, faust wrote:
Hi
In what way i cat implement validation of uniqueness?
User
email: unique
login: unique
You can only have 1 unique field per database.
Why too documents?
But i have one issue User
i need only one document .
i am interesting, how couch people do in real projects.
when they need two unique fields in document.
2010/3/28 Jan Lehnardt j...@apache.org:
You need to have two documents with a unique ID each.
Cheers
Jan
--
On
27 matches
Mail list logo
