You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Clément Vollet <cv...@gmail.com> on 2011/04/20 19:46:08 UTC
Help needed: is couchDB a good fit for my app?
Hello everybody,
First of all, I want to say that I'm quite impressed with couchDB so far
(I didn't know anaything about it two days ago...).
Second, I'd really want to use it for my app (I stumbled upon couchdb
searching for a database that fits my requirements in fact). I manage to
cross a few items off my list, but I'm still not sure couchDB is a good
fit, and my boss wants an answer by tomorrow.
So, to summarize what I want to do (it's really simple in fact): I'd
want to be able to have a list of public documents, have a list of tags
definition (name, default value, possible values...), and then users can
*privately* tag those documents. So, the items and the tag definitions
are public, the tag values are private. And finally, I'd like to be able
to have stats on those values, like XX% of the users used the same value
for this document and this tag.
And that's it. It would be in a phone app, and I'd really like to use
replication to have a client cache for values and an offline mode. There
would of course also be a central server for bootstrap, updates,
reliability, ...
So, CouchDB seems like a really good fit, but I'm stuck on the privacy
thing. What I came with so far, was to have separate documents for
items, tags, and tag values, but how can I make sure only the user who
wrote the value can read it without per document authorization (I
already read the wiki page about that, but none of the solution seems
ideal)?
Best regards,
Clément
Re: Help needed: is couchDB a good fit for my app?
Posted by Hendrik Jan van Meerveld <ha...@gmail.com>.
Hi Clement,
I can think of two other options.
They are not perfect but easier to implement:
1. ------
You can use a "Public Docs" database and a "User database" (one User
database per user) like Ryan suggests
When someone tags or un-tags a document the application does two writes:
- a write to the Public Docs database to update a counter
{"type":"tagcounter", "docid":"mydoc", "tag":"mytag", "count":count+1}
- a write to the User database to register the private tag
That way you can easily get stats from the Public Docs while the user tags
cannot be read by anyone except the user.
Of course a problem could arise when the writing to one of the two databases
fails.
2. ------
You can give every user a random code like
{
"type":"user",
"user":"John Smith",
"randomCode":"aslieghahsdfhlajsreij"
}
and then the user creates document tags (in the same database) like:
{
"type":"document tag",
"userCode":"aslieghahsdfhlajsreij",
"documentId":"mydoc",
"tag":"mytag"
}
This is really easy implementing and might be safe enough for your case.
And you might be able to scramble the randomCode with the user password so
it would become more difficult to find out which code belongs to which
user.
Kind regards,
Hendrik Jan
On 21 April 2011 18:39, Ryan Ramage <ry...@gmail.com> wrote:
> You might want some architecture like this:
>
> [] Public Docs db |
> | <----- hosted
> [] User 1db [] User 2 db [].... |
> ------------------------------------------------------
>
> [] User1 phone db [] User 2 Phonedb []....
>
>
>
> My ascii art is not very good :)
>
> Then have replication between phone and user db. Then have replication
> from Userdb to public docs db with a filter to take out private
> tags...
>
>
> Does that work?
>
> Ryan
>
>
>
>
>
>
>
> 2011/4/20 Clément Vollet <cv...@gmail.com>:
> > Hello everybody,
> >
> > First of all, I want to say that I'm quite impressed with couchDB so far
> > (I didn't know anaything about it two days ago...).
> >
> > Second, I'd really want to use it for my app (I stumbled upon couchdb
> > searching for a database that fits my requirements in fact). I manage to
> > cross a few items off my list, but I'm still not sure couchDB is a good
> > fit, and my boss wants an answer by tomorrow.
> >
> > So, to summarize what I want to do (it's really simple in fact): I'd
> > want to be able to have a list of public documents, have a list of tags
> > definition (name, default value, possible values...), and then users can
> > *privately* tag those documents. So, the items and the tag definitions
> > are public, the tag values are private. And finally, I'd like to be able
> > to have stats on those values, like XX% of the users used the same value
> > for this document and this tag.
> >
> > And that's it. It would be in a phone app, and I'd really like to use
> > replication to have a client cache for values and an offline mode. There
> > would of course also be a central server for bootstrap, updates,
> > reliability, ...
> >
> > So, CouchDB seems like a really good fit, but I'm stuck on the privacy
> > thing. What I came with so far, was to have separate documents for
> > items, tags, and tag values, but how can I make sure only the user who
> > wrote the value can read it without per document authorization (I
> > already read the wiki page about that, but none of the solution seems
> > ideal)?
> >
> > Best regards,
> >
> > Clément
> >
>
Re: Help needed: is couchDB a good fit for my app?
Posted by Clément Vollet <cv...@gmail.com>.
Le 21/04/2011 11:23, Ryan Ramage a écrit :
>>> You might want some architecture like this:
>>>
>>> [] Public Docs db |
>>> | <----- hosted
>>> [] User 1db [] User 2 db [].... |
>>> ------------------------------------------------------
>>>
>>> [] User1 phone db [] User 2 Phonedb []....
>>>
>>> Then have replication between phone and user db. Then have replication
>>> from Userdb to public docs db with a filter to take out private
>>> tags...
>>>
>
>> Hum, something like that could yes. But I have a question regarding the
>> stats. First, a tag can only take a value in a predefined set of value
>> for that tag. So, is it possible that instead of filtering the tag
>> completely, I update the stat of the value accordingly (+1 if the value
>> has been chosen by the user, -1 if the user changed to another value or
>> reset the tag)?
> CouchDB filtering is currently a yes/no operation per doc. So you
> would want to have related docs to the tag that hold the 'stat of the
> value'. Filter the parent tag doc, and let the 'stat of the value'
> docs go back to the public db.
>
Ok, that could work then.
>> Oh, and also, I read that there is a limit depending on the OS for the
>> number of concurrent databases. Won't that be a problem if there is a
>> lot of users (which will hopefully be the case;)?
> Yes, there will be a limit on how many for concurrent dbs per OS. It
> is really high anyway. Someone else will have to give real life
> numbers on this. But if you hit the wall, just add more servers. They
> are cheap as chips :) The couch replication model is nice because it
> is flexible with how you might grow.
>
All right, well, thanks for everything, I'll see if I can convince my
boss now ;)
> Ryan
Re: Help needed: is couchDB a good fit for my app?
Posted by Clément Vollet <cv...@gmail.com>.
Le 21/04/2011 12:09, Sean Copenhaver a écrit :
> Not saying that a database per user isn't a good idea (probably would work
> pretty well with the future replication database feature), but some
> alternatives that I could think of are:
>
> You could potentially have something in front of couchdb to restrict the
> access to regular doc GET/POST/PUT and force the outside world to pull using
> show and list functions. I believe you could user the user's context/session
> object that is in the request object (pretty sure show/list get it) to
> filter out the non-user/public data. You'll probably have to always use
> update functions as well to avoid overriding tags.
>
> That or perhaps have the generic document stand alone and then the user
> specific stuff in a separate document owned by the user. I believe still in
> this scenario you would have to put something in front of couchdb to
> restrict access if they are private. You would be able to make use of
> filters for replication and changes pretty effectively I think.
>
Hum, that may be another option yes. Thanks, that provides me with
another argument to convince my boss to use CouchDB (which seems, quite
frankly, awesome).
> On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage <ry...@gmail.com> wrote:
>
>>>> You might want some architecture like this:
>>>>
>>>> [] Public Docs db |
>>>> | <----- hosted
>>>> [] User 1db [] User 2 db [].... |
>>>> ------------------------------------------------------
>>>>
>>>> [] User1 phone db [] User 2 Phonedb []....
>>>>
>>>> Then have replication between phone and user db. Then have replication
>>>> from Userdb to public docs db with a filter to take out private
>>>> tags...
>>>>
>>
>>> Hum, something like that could yes. But I have a question regarding the
>>> stats. First, a tag can only take a value in a predefined set of value
>>> for that tag. So, is it possible that instead of filtering the tag
>>> completely, I update the stat of the value accordingly (+1 if the value
>>> has been chosen by the user, -1 if the user changed to another value or
>>> reset the tag)?
>> CouchDB filtering is currently a yes/no operation per doc. So you
>> would want to have related docs to the tag that hold the 'stat of the
>> value'. Filter the parent tag doc, and let the 'stat of the value'
>> docs go back to the public db.
>>
>>> Oh, and also, I read that there is a limit depending on the OS for the
>>> number of concurrent databases. Won't that be a problem if there is a
>>> lot of users (which will hopefully be the case;)?
>> Yes, there will be a limit on how many for concurrent dbs per OS. It
>> is really high anyway. Someone else will have to give real life
>> numbers on this. But if you hit the wall, just add more servers. They
>> are cheap as chips :) The couch replication model is nice because it
>> is flexible with how you might grow.
>>
>> Ryan
>>
>
>
Re: Help needed: is couchDB a good fit for my app?
Posted by Sean Copenhaver <se...@gmail.com>.
Not saying that a database per user isn't a good idea (probably would work
pretty well with the future replication database feature), but some
alternatives that I could think of are:
You could potentially have something in front of couchdb to restrict the
access to regular doc GET/POST/PUT and force the outside world to pull using
show and list functions. I believe you could user the user's context/session
object that is in the request object (pretty sure show/list get it) to
filter out the non-user/public data. You'll probably have to always use
update functions as well to avoid overriding tags.
That or perhaps have the generic document stand alone and then the user
specific stuff in a separate document owned by the user. I believe still in
this scenario you would have to put something in front of couchdb to
restrict access if they are private. You would be able to make use of
filters for replication and changes pretty effectively I think.
On Thu, Apr 21, 2011 at 2:23 PM, Ryan Ramage <ry...@gmail.com> wrote:
> >> You might want some architecture like this:
> >>
> >> [] Public Docs db |
> >> | <----- hosted
> >> [] User 1db [] User 2 db [].... |
> >> ------------------------------------------------------
> >>
> >> [] User1 phone db [] User 2 Phonedb []....
> >>
> >> Then have replication between phone and user db. Then have replication
> >> from Userdb to public docs db with a filter to take out private
> >> tags...
> >>
>
>
> > Hum, something like that could yes. But I have a question regarding the
> > stats. First, a tag can only take a value in a predefined set of value
> > for that tag. So, is it possible that instead of filtering the tag
> > completely, I update the stat of the value accordingly (+1 if the value
> > has been chosen by the user, -1 if the user changed to another value or
> > reset the tag)?
>
> CouchDB filtering is currently a yes/no operation per doc. So you
> would want to have related docs to the tag that hold the 'stat of the
> value'. Filter the parent tag doc, and let the 'stat of the value'
> docs go back to the public db.
>
> >
> > Oh, and also, I read that there is a limit depending on the OS for the
> > number of concurrent databases. Won't that be a problem if there is a
> > lot of users (which will hopefully be the case;)?
>
> Yes, there will be a limit on how many for concurrent dbs per OS. It
> is really high anyway. Someone else will have to give real life
> numbers on this. But if you hit the wall, just add more servers. They
> are cheap as chips :) The couch replication model is nice because it
> is flexible with how you might grow.
>
> Ryan
>
--
“The limits of language are the limits of one's world. “ -Ludwig von
Wittgenstein
Re: Help needed: is couchDB a good fit for my app?
Posted by Ryan Ramage <ry...@gmail.com>.
>> You might want some architecture like this:
>>
>> [] Public Docs db |
>> | <----- hosted
>> [] User 1db [] User 2 db [].... |
>> ------------------------------------------------------
>>
>> [] User1 phone db [] User 2 Phonedb []....
>>
>> Then have replication between phone and user db. Then have replication
>> from Userdb to public docs db with a filter to take out private
>> tags...
>>
> Hum, something like that could yes. But I have a question regarding the
> stats. First, a tag can only take a value in a predefined set of value
> for that tag. So, is it possible that instead of filtering the tag
> completely, I update the stat of the value accordingly (+1 if the value
> has been chosen by the user, -1 if the user changed to another value or
> reset the tag)?
CouchDB filtering is currently a yes/no operation per doc. So you
would want to have related docs to the tag that hold the 'stat of the
value'. Filter the parent tag doc, and let the 'stat of the value'
docs go back to the public db.
>
> Oh, and also, I read that there is a limit depending on the OS for the
> number of concurrent databases. Won't that be a problem if there is a
> lot of users (which will hopefully be the case;)?
Yes, there will be a limit on how many for concurrent dbs per OS. It
is really high anyway. Someone else will have to give real life
numbers on this. But if you hit the wall, just add more servers. They
are cheap as chips :) The couch replication model is nice because it
is flexible with how you might grow.
Ryan
Re: Help needed: is couchDB a good fit for my app?
Posted by Clément Vollet <cv...@gmail.com>.
Le 21/04/2011 09:39, Ryan Ramage a écrit :
> You might want some architecture like this:
>
> [] Public Docs db |
> | <----- hosted
> [] User 1db [] User 2 db [].... |
> ------------------------------------------------------
>
> [] User1 phone db [] User 2 Phonedb []....
>
>
>
> My ascii art is not very good :)
>
> Then have replication between phone and user db. Then have replication
> from Userdb to public docs db with a filter to take out private
> tags...
>
Arg, I spammed the ml with a second message since I didn't show mine on
the it. Sorry for that
(and thanks for answering ;).
> Does that work?
>
Hum, something like that could yes. But I have a question regarding the
stats. First, a tag can only take a value in a predefined set of value
for that tag. So, is it possible that instead of filtering the tag
completely, I update the stat of the value accordingly (+1 if the value
has been chosen by the user, -1 if the user changed to another value or
reset the tag)?
Oh, and also, I read that there is a limit depending on the OS for the
number of concurrent databases. Won't that be a problem if there is a
lot of users (which will hopefully be the case;)?
Thanks again for your answer,
Regards,
Clément
> Ryan
>
>
>
>
>
>
>
> 2011/4/20 Clément Vollet <cv...@gmail.com>:
>> Hello everybody,
>>
>> First of all, I want to say that I'm quite impressed with couchDB so far
>> (I didn't know anaything about it two days ago...).
>>
>> Second, I'd really want to use it for my app (I stumbled upon couchdb
>> searching for a database that fits my requirements in fact). I manage to
>> cross a few items off my list, but I'm still not sure couchDB is a good
>> fit, and my boss wants an answer by tomorrow.
>>
>> So, to summarize what I want to do (it's really simple in fact): I'd
>> want to be able to have a list of public documents, have a list of tags
>> definition (name, default value, possible values...), and then users can
>> *privately* tag those documents. So, the items and the tag definitions
>> are public, the tag values are private. And finally, I'd like to be able
>> to have stats on those values, like XX% of the users used the same value
>> for this document and this tag.
>>
>> And that's it. It would be in a phone app, and I'd really like to use
>> replication to have a client cache for values and an offline mode. There
>> would of course also be a central server for bootstrap, updates,
>> reliability, ...
>>
>> So, CouchDB seems like a really good fit, but I'm stuck on the privacy
>> thing. What I came with so far, was to have separate documents for
>> items, tags, and tag values, but how can I make sure only the user who
>> wrote the value can read it without per document authorization (I
>> already read the wiki page about that, but none of the solution seems
>> ideal)?
>>
>> Best regards,
>>
>> Clément
>>
Re: Help needed: is couchDB a good fit for my app?
Posted by Ryan Ramage <ry...@gmail.com>.
You might want some architecture like this:
[] Public Docs db |
| <----- hosted
[] User 1db [] User 2 db [].... |
------------------------------------------------------
[] User1 phone db [] User 2 Phonedb []....
My ascii art is not very good :)
Then have replication between phone and user db. Then have replication
from Userdb to public docs db with a filter to take out private
tags...
Does that work?
Ryan
2011/4/20 Clément Vollet <cv...@gmail.com>:
> Hello everybody,
>
> First of all, I want to say that I'm quite impressed with couchDB so far
> (I didn't know anaything about it two days ago...).
>
> Second, I'd really want to use it for my app (I stumbled upon couchdb
> searching for a database that fits my requirements in fact). I manage to
> cross a few items off my list, but I'm still not sure couchDB is a good
> fit, and my boss wants an answer by tomorrow.
>
> So, to summarize what I want to do (it's really simple in fact): I'd
> want to be able to have a list of public documents, have a list of tags
> definition (name, default value, possible values...), and then users can
> *privately* tag those documents. So, the items and the tag definitions
> are public, the tag values are private. And finally, I'd like to be able
> to have stats on those values, like XX% of the users used the same value
> for this document and this tag.
>
> And that's it. It would be in a phone app, and I'd really like to use
> replication to have a client cache for values and an offline mode. There
> would of course also be a central server for bootstrap, updates,
> reliability, ...
>
> So, CouchDB seems like a really good fit, but I'm stuck on the privacy
> thing. What I came with so far, was to have separate documents for
> items, tags, and tag values, but how can I make sure only the user who
> wrote the value can read it without per document authorization (I
> already read the wiki page about that, but none of the solution seems
> ideal)?
>
> Best regards,
>
> Clément
>