On Feb 21, 2013, at 11:31 PM, "Elisiano Petrini" wrote:
> I understand the concept, but on the same level there could be more than
> one child. Using this as an ID would work only if you put something
> unique to the node in composing the ID.
>
I don't recall multiple nodes being a constraint
Ah OK, I get the point now, you put something unique to the node in the
ID (in this case a sequential number).
But still, see the concern in my previous mail.
This approach works if the client has the logic to re-try (with an
incremented sequence number) in case of collisions.
Cheers, Elisano
On
I understand the concept, but on the same level there could be more than
one child. Using this as an ID would work only if you put something
unique to the node in composing the ID.
Generating a sequential ID (per tree level) depending on the order of
arrival might lead to collisions (if messages a
Sent from my iPhone
On Feb 21, 2013, at 11:11 PM, "Elisiano Petrini" wrote:
> Hi Kim,
>I don't think using this kind of documents' ids is a viable
> solution: what if there is more that one message in response to another
> (ie:several people answering to the same message)?
>
Nope. Works
that's the path to root stored as id
so answers to 1-2 will be say 1-2-5 1-2-6 1-2-33
> Hi Kim,
> I don't think using this kind of documents' ids is a viable
> solution: what if there is more that one message in response to
> another (ie:several people answering to the same message)?
>
> On F
Hi Kim,
I don't think using this kind of documents' ids is a viable
solution: what if there is more that one message in response to another
(ie:several people answering to the same message)?
On Fri, 2013-02-22 at 07:00 +, Jim Klo wrote:
> In theory you mention infinite depth, but is that r
@Elisiano: having references to children is redundant. You can simply build
a view to get children by immediate parents.
@Jim: you are right. I've never seen a thread deeper than 20-30 levels. And
I actually feel like I'm exaggerating here. :)
On Fri, Feb 22, 2013 at 3:04 PM, Elisiano Petrini wr
Hi All,
please forgive me if I'm missing/overlooking something here, I'm not
a couchdb expert.
It all depends on the needs of the project but usually one would want to
trasverse the tree from the root node down to its children.
In every implementation of trees that I've seen (and done) so far,
In theory you mention infinite depth, but is that realistic?
A simple way is to make ID's a composite serial and chain them together.
1 : orig message
1-2 : reply to 1
1-2-5 : reply to 2
1-3 : reply to 1
1-3-4 : reply to
The keys will then sort in order, such that can build the tree DFS and u
andrey, svilen, many thanks again.
agreed, storing immediate children in a document is a bad idea. i think
i go for storing only an immediate parent id to get an infinite tree depth.
thanks for your inspirations guys
cheers
michael
On 22/02/13 18:49, Andrey Kuprianov wrote:
PS - storing onl
PS - storing only an immediate parent id would be the solution for an
infinite tree depth.
On Fri, Feb 22, 2013 at 1:48 PM, Andrey Kuprianov <
andrey.koupria...@gmail.com> wrote:
> Storing immediate children in a parent is a bad idea in a sense that you
> will never be able to traverse your tree
another way (useless in your case) is to keep messages as separate
docs, and keep a cache of the structure of the tree (id,(id,id)...)) as
another doc.
if u have the notion of closed/frozen threads, that might be of use.
actualy that cache can be a dict:
{ parent_id: [ list of children_id ] }
svi
Storing immediate children in a parent is a bad idea in a sense that you
will never be able to traverse your tree back to the root, given a child
node.
Storing all in one doc - you will run out of space before you know it.
Documents have a finite length and the larger the document, the slower it
w
well that was just an idea..
each "doc" is the list of it's direct children (and does not contain
it's own node data). + one special doc about the root, if needed.
i guess may be unusable in most cases.
by dicts i meant same like lists but having node-id as key.
http://en.wikipedia.org/wiki/Neste
thanks andrey and svil
depth is infinite. in theory a message can have million replies forth
and back. similar like a very long email thread.
i think storing ancestors à la andrey would be too much hassle but works
well for few levels.
svil, what did you mean with dicts and with keeping all
my rough guess:
if it's finite depth, then all in one doc:
- list of (item or (list of ...))
- or same with dicts
else, one doc per message keeping just link-to-parent,
or multiple links-to-grand...grand-parents and/or root.
similar to the strategies in SQL - nested etc.
keeping all chidlren of
Hi Michael,
In our case we do it by storing a whole list of ancestor IDs on the
children nodes. Then, given ancestor ID, we can pull all the children nodes
and then build tree programmatically, if so needed.
You will need a view for that, where each ancestor ID is a key. Here's a
snippet:
if(doc
Hello guys
I'd like to store messages in a tree like structure. Whenever you reply
to a message, then the original message becomes the parent message.
How would you implement something like this in CouchDB? Just curious and
need a little guidance + advice here.
Thanks,
Michael
--
Binary K
>(FYI, Couchbase is now actively looking to hire an engineer to work on
>finishing TouchDB for Android!)
hmm. i might be able/interested to help although i do have tons of stuff
to do right now.
see www.svilendobrev.com about who and what and why i am
ciao
svil
Please ignore my last message. Caching is hard.
On 20 February 2013 23:08, Jan Lehnardt wrote:
> Hi,
>
> thanks for all your help getting the 1.2.1 Mac OS X binaries into shape.
> I’ve put them on the website for general distribution now:
>
> http://couchdb.apache.org#download
>
> Special t
Jan, I don't see these on the website.
On 20 February 2013 23:08, Jan Lehnardt wrote:
> Hi,
>
> thanks for all your help getting the 1.2.1 Mac OS X binaries into shape.
> I’ve put them on the website for general distribution now:
>
> http://couchdb.apache.org#download
>
> Special thanks to
You can prevent writes with a validate_doc_update function. Check the user
context and throw if it's not an admin.
What version of CouchDB are you running? In newer versions (I can't recall
the exact version where it was added) you can't access all_docs on the
users db unless you are an admin.
On
Michael Bykov wrote:
2013/2/21 Lenin
I have tried un installed couchdb which is installed from source, how to
uninstall please help me
Hi, Vladimir Ilyich!
sudo rm -rf /
will remove it completely, yes.
Haven't looked lately, but I assume that "make uninstall" and "make
distclean" an
I have tried un installed couchdb which is installed from source, how to
uninstall please help me
It would be safer to always add "email:" at the front and always strip
the first six characters, rather than look for the colon.
B.
On 21 February 2013 11:25, svilen wrote:
> yes, i did so. the ':' is invalid for emails, so it's easy to decide
> whether to strip/prepend or not
>
> On Thu, 21 Feb
true
My need was to associate users with a document database with the same name
(the names of the databases have many constraints)
2013/2/21 svilen
> yeah good for hiding it, but still has to store it elsewhere, and
> theoreticaly, it might repeat.
>
> On Thu, 21 Feb 2013 12:12:43 +0100
> Vince
yes, i did so. the ':' is invalid for emails, so it's easy to decide
whether to strip/prepend or not
On Thu, 21 Feb 2013 11:14:27 +
Robert Newson wrote:
> correct, you can't start a doc id with _. It seems simple enough to
> solve this by prefixing "email:" to your ids.
>
> B.
>
> On 21 Fe
yeah good for hiding it, but still has to store it elsewhere, and
theoreticaly, it might repeat.
On Thu, 21 Feb 2013 12:12:43 +0100
Vincenzo Scolaro wrote:
> I had the same need and I did it this way
> id = md5 (email)
>
> What do you think?
>
> Vincenzo
>
>
> 2013/2/21 svilen
>
> > hi
> >
correct, you can't start a doc id with _. It seems simple enough to
solve this by prefixing "email:" to your ids.
B.
On 21 February 2013 11:12, Vincenzo Scolaro wrote:
> I had the same need and I did it this way
> id = md5 (email)
>
> What do you think?
>
> Vincenzo
>
>
> 2013/2/21 svilen
>
>>
I had the same need and I did it this way
id = md5 (email)
What do you think?
Vincenzo
2013/2/21 svilen
> hi
> the docs state that anything can be put in _id, except that it can't
> start with "_" underscore.
>
> still, the _ is valid character for starting email address...
> effectively mean
hi
the docs state that anything can be put in _id, except that it can't
start with "_" underscore.
still, the _ is valid character for starting email address...
effectively meaning that in general, e-mail addresses cannot be used as
id (the only enforced unique thing).. and has to be stored as a f
Sounds like https://issues.apache.org/jira/browse/COUCHDB-1415
B.
On 21 February 2013 05:06, Daniel Bell wrote:
> Hi,
>
> I've found what I believe is a couchdb error under specific circumstances:
>
> 1. create doc with user-specified _id
> 2. delete doc
> 3. compact database
> 4. create same do
On Sunday, February 17, 2013, Mike Harding wrote:
> hi Алекс, Thanks for your response!
>
> Am I correct in assuming in this script
>
> https://github.com/apache/couchdb/blob/master/share/www/script/test/oauth.js
> that the test user 'jason' is defined as a oauth user in the couchdb
> default.ini
33 matches
Mail list logo
