> > > I know I can put the 'name' in the '_id' field but I'd like to avoid it >> because I'm abstracting CouchDB and the abstraction does not allow for it. >> > > Why is that? >
Amongst other things, the framework can join CouchDB tables to SQL tables. To allow this to happen, we need to be able to easily share references through an id field. I use a :bigint like field to handle this. Not consistently knowing that the id is a :bigint will incur a lot of code overhead where the code is very clean otherwise. In some cases, we also need to have uniqueness based on two fields. This would be even harder to store as the lone _id field, particularly since CouchDB seems to convert all ids to String. But, because of the ability to join between two database types, we can use the database that is the best fit for our needs with more or less the same code. For example: * Where schema doesn't change often and it has to do with transactional data, we prefer SQL. A good example might be data to do with money transactions. * Where schema needs to be updated often and the data is not very transactional, we prefer CouchDB. For example, pages in a website. Over time, we might add tags, or descriptions to those pages. We also might introduce new page types, some of which support different fields. In this case, CouchDB is preferred. Note that models are defined and the API is almost exactly the same between CouchDB and SQL. The main difference is we define and use "indexes" in SQL and "views" in CouchDB. It uses similar syntax to Ruby Sequel (and in fact uses Sequel as a backend for the SQL API). > > Anybody have any solutions other than making 'name' the '_id' field? >> > > You'd need some service that acts as global state outside of CouchDB > that ensures it only allows one client to take a certain name. CouchDB > won't do that for you. > > Cheers > Jan > -- > I wanted to do this automatically somehow. I considered storing unique values in an outside SQL table just for those unique fields and have it check automatically against that. Unfortunately, there still seems to be edge cases that would make this inconsistent. For example, if during the commit, one or more databases failed. Of course, we could work around those as well, but now there is a lot of stuff going on to do an insert or update that messies up the code. I don't like the junk it adds. Unless anybody can think of a way to guarantee uniqueness in CouchDB, I think I am going to abandon the notion of GUARANTEED uniqueness and instead implementcode to PREFER uniqueness. Then at the end of the day, we can write some code that will tell us if that 1 in a million chance (i.e. two simultaneous inserts/updates) left our database in a state where there are two docs with the same unique field. Since the odds are quite low that it will actually happen, I think we can deal with the times that it happens manually so long as we know about it. Sunny
