You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by ken tashiro <pr...@gmail.com> on 2015/04/15 11:55:58 UTC
how to use an included document's key?
Hi,
I have a question. Suppose documents are
[
{ "_id": "11111" },
{ "_id": "22222", "ancestors": ["11111"], "value": "hello" },
{ "_id": "33333", "ancestors": ["22222","11111"], "value": "world" }
]
like
http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views#Linked_documents
and "include_docs=true".
I want to make a map function like
function(doc) {
if (doc.ancestors) {
for (var i in doc.ancestors) {
if ( doc.value === 'world' AND ' value of ancestor is "hello" ' ) {
emit (doc._id,ancestor's id);
}
}
}
}
and get {"key":"33333",value:"22222"}.
My question is how can I use an included document and know
"value of ancestor" ?
Thank you.
ken tashiro
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you for your advice,Matthieu.
> An other solution (I think that's what Giovanni points out) is to
> _not_ put phases in the prescription:
>
> - When you have a new prescription, just write it to the database
>
> - To know the current phase, retrieve the 2 last doc for each
> prescriber (you can use your second query here). Since you already put
> the current prescription, this will give you the current and the last,
> and then you diff in your application. For each drug you know if it
> was there in the previous prescription or not, so you can derive phase
> for each drug. I'm not 100% sure, but you could even build a _reduce
> that creates the result for you here.
>
> Now with this you may have a problem of consistency: if one of your
> databases has the 2 last documents, but another database isn't
> perfectly synced, both databases may not give you the same output.
> This is kind of expected since your phases span multiple documents. If
> you have the last prescription id in the current prescription though,
> you at least know if you lack any of them (but you can't do anything
> without first syncing)
I was not careful about consistency.
Surely I should think about it.
ken tashiro
Re: MapReduce Simulator (Fwd: how to use an included document's key?)
Posted by Andy Wenk <an...@apache.org>.
yes +1. This is cool.
Jan, can you remember the tool where one could try out map reduce? It was
really nice and I can't remember why it's gone ...
All the best
Andy
On 21 April 2015 at 10:16, Alexander Shorin <kx...@gmail.com> wrote:
> On Tue, Apr 21, 2015 at 10:42 AM, Jan Lehnardt <ja...@apache.org> wrote:
> > I just found http://fiatjaf.alhur.es/couchdb-mr-simulator/ on user@.
> >
> > Would this make a great addition to Fauxton?
>
> +1 nice found
>
> --
> ,,,^..^,,,
>
--
Andy Wenk
Hamburg - Germany
RockIt!
GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
https://people.apache.org/keys/committer/andywenk.asc
Re: MapReduce Simulator (Fwd: how to use an included document's key?)
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Apr 21, 2015 at 10:42 AM, Jan Lehnardt <ja...@apache.org> wrote:
> I just found http://fiatjaf.alhur.es/couchdb-mr-simulator/ on user@.
>
> Would this make a great addition to Fauxton?
+1 nice found
--
,,,^..^,,,
MapReduce Simulator (Fwd: how to use an included document's key?)
Posted by Jan Lehnardt <ja...@apache.org>.
I just found http://fiatjaf.alhur.es/couchdb-mr-simulator/ on user@.
Would this make a great addition to Fauxton?
Best
Jan
--
> Begin forwarded message:
>
> From: ken tashiro <pr...@gmail.com>
> Subject: Re: how to use an included document's key?
> Date: 21 Apr 2015 05:28:57 CEST
> To: user@couchdb.apache.org, Giovanni Parra <fi...@gmail.com>
> Reply-To: user@couchdb.apache.org
>
> Thank you for your advice, Giovanni.
>
> 2015-04-20 21:51 GMT+09:00 Giovanni P <fi...@gmail.com>:
>> After thinking more about it, I think that the optimal suggestion (in the
>> sense that I want you to consider that my only suggestion from now on) is
>> to have one document for each patient visits to the pharmacy, as Sebastian
>> said.
>>
>> The document structure could be something like this
>> <http://pastie.org/10103158>.
>
> I was puzzled about how to update efficiently a document each time
> keeping consistencybut this "one document per one event"
> structure is very easy to handle.
>
>> At every visit, even if nothing happened on that visit, you would have a
>> new document with all the current "state" information about the patient. It
>> would list all the drugs being continuously taken, drugs that were stopped
>> (after they being "stopped" in one document, they would not appear in the
>> next documents), even drugs the patient reported to be taking before the
>> first visit, or that he is taking because they were prescribed elsewhere.
>
> I think you are pointing to the core of pharmacist business.
> The patient information without prescription is now recorded on a paper,
> and the problem is how it should be recorded electrically. Since this is
> a difficult problem, I have lowered this priority, but I was wrong.
>
>> The GUI interface should, them, get the last document for each patient, and
>> display the "current state" for the pharmacist, who can ask about all the
>> drugs, for example: "are you still taking xyz?", if the patient forgets
>> about it. Then all the updates the pharmacist makes on the screen can be
>> saved just as they are, but AS A NEW DOCUMENT, old documents should be
>> considered as immutable (maybe editable only in case of error).
>
> I also thought previous prescriptions should be immutable, so I put
> optional "phase 3" information at the timing of creating a new document for
> the current prescription document (The number of GET and PUT has
> become relatively minor problem in my brain). Now your suggestion is to add
> a new document whenever a patient gives any information, I should do this.
>
>> Information about the patients (as you said you want to track reactions
>> considering age, gender and other things) could be then emitted as you
>> like. For example, for querying stopped drugs of some type for patients
>> with ages between 24 and 34, you would have a view emitting keys like this:
>> [phase, drug type, patient's age], and a result like this
>> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
>> _count\nreduce: true\ngroup_level: 3\nstartkey: [3, X, 24, null]\nendkey:
>> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
>> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
>> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
>> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
>> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
>> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
>> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
>> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
>> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
>> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
>> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
>> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
>> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
>> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
>> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
>> Xoliryi-43"}>. Now, if you wanted to get the results discriminated by the
>> drug name, the query would be this
>> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
>> _count\nreduce: true\ngroup_level: 4\nstartkey: [3, X, 24, null]\nendkey:
>> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
>> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
>> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
>> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
>> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
>> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
>> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
>> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
>> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
>> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
>> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
>> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
>> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
>> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
>> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
>> Xoliryi-43"}>.
>
> Thank you for detailed sample,and I am surprised that such a
> simulation site exists.
>
> Sincerely yours, ken tashiro.
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you for your advice, Giovanni.
2015-04-20 21:51 GMT+09:00 Giovanni P <fi...@gmail.com>:
> After thinking more about it, I think that the optimal suggestion (in the
> sense that I want you to consider that my only suggestion from now on) is
> to have one document for each patient visits to the pharmacy, as Sebastian
> said.
>
> The document structure could be something like this
> <http://pastie.org/10103158>.
I was puzzled about how to update efficiently a document each time
keeping consistencybut this "one document per one event"
structure is very easy to handle.
> At every visit, even if nothing happened on that visit, you would have a
> new document with all the current "state" information about the patient. It
> would list all the drugs being continuously taken, drugs that were stopped
> (after they being "stopped" in one document, they would not appear in the
> next documents), even drugs the patient reported to be taking before the
> first visit, or that he is taking because they were prescribed elsewhere.
I think you are pointing to the core of pharmacist business.
The patient information without prescription is now recorded on a paper,
and the problem is how it should be recorded electrically. Since this is
a difficult problem, I have lowered this priority, but I was wrong.
> The GUI interface should, them, get the last document for each patient, and
> display the "current state" for the pharmacist, who can ask about all the
> drugs, for example: "are you still taking xyz?", if the patient forgets
> about it. Then all the updates the pharmacist makes on the screen can be
> saved just as they are, but AS A NEW DOCUMENT, old documents should be
> considered as immutable (maybe editable only in case of error).
I also thought previous prescriptions should be immutable, so I put
optional "phase 3" information at the timing of creating a new document for
the current prescription document (The number of GET and PUT has
become relatively minor problem in my brain). Now your suggestion is to add
a new document whenever a patient gives any information, I should do this.
> Information about the patients (as you said you want to track reactions
> considering age, gender and other things) could be then emitted as you
> like. For example, for querying stopped drugs of some type for patients
> with ages between 24 and 34, you would have a view emitting keys like this:
> [phase, drug type, patient's age], and a result like this
> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
> _count\nreduce: true\ngroup_level: 3\nstartkey: [3, X, 24, null]\nendkey:
> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
> Xoliryi-43"}>. Now, if you wanted to get the results discriminated by the
> drug name, the query would be this
> <http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
> _count\nreduce: true\ngroup_level: 4\nstartkey: [3, X, 24, null]\nendkey:
> [3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
> drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
> Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
> Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
> Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
> A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
> Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
> Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
> Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
> Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
> Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
> Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
> Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
> Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
> Xoliryi-43"}>.
Thank you for detailed sample,and I am surprised that such a
simulation site exists.
Sincerely yours, ken tashiro.
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
After thinking more about it, I think that the optimal suggestion (in the
sense that I want you to consider that my only suggestion from now on) is
to have one document for each patient visits to the pharmacy, as Sebastian
said.
The document structure could be something like this
<http://pastie.org/10103158>.
At every visit, even if nothing happened on that visit, you would have a
new document with all the current "state" information about the patient. It
would list all the drugs being continuously taken, drugs that were stopped
(after they being "stopped" in one document, they would not appear in the
next documents), even drugs the patient reported to be taking before the
first visit, or that he is taking because they were prescribed elsewhere.
The GUI interface should, them, get the last document for each patient, and
display the "current state" for the pharmacist, who can ask about all the
drugs, for example: "are you still taking xyz?", if the patient forgets
about it. Then all the updates the pharmacist makes on the screen can be
saved just as they are, but AS A NEW DOCUMENT, old documents should be
considered as immutable (maybe editable only in case of error).
Information about the patients (as you said you want to track reactions
considering age, gender and other things) could be then emitted as you
like. For example, for querying stopped drugs of some type for patients
with ages between 24 and 34, you would have a view emitting keys like this:
[phase, drug type, patient's age], and a result like this
<http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
_count\nreduce: true\ngroup_level: 3\nstartkey: [3, X, 24, null]\nendkey:
[3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
Xoliryi-43"}>. Now, if you wanted to get the results discriminated by the
drug name, the query would be this
<http://fiatjaf.alhur.es/couchdb-mr-simulator/#{"params":"reduceFn:
_count\nreduce: true\ngroup_level: 4\nstartkey: [3, X, 24, null]\nendkey:
[3, X, 34, {}]","emitted":"# key: phase, drug type, patient age\n# value:
drug name\n1, X, 21, Xoliryi-43\n1, A, 29, Aaayol-43\n1, Y, 24,
Yaayol-43\n2, A, 22, Aaayol-43\n3, Y, 22, Yoliryi-43\n3, X, 39,
Xoliryi-43\n1, A, 49, Aoliryi-43\n1, Y, 24, Yeeeu-43\n2, A, 32,
Aeeeu-43\n2, A, 33, Aaayol-43\n2, X, 44, Xaayol-43\n3, Y, 22, Yaayol-43\n2,
A, 43, Aoliryi-43\n1, Y, 31, Yoliryi-43\n2, X, 22, Xoliryi-43\n2, X, 23,
Xoliryi-43\n2, X, 44, Xoliryi-43\n2, A, 23, Aeeeu-43\n3, A, 34,
Aaayol-43\n1, Y, 21, Yaayol-43\n2, X, 22, Xaayol-43\n2, X, 23,
Xaayol-43\n2, X, 24, Xaayol-43\n3, Y, 22, Yaayol-43\n3, X, 29,
Xaayol-43\n1, A, 49, Aaayol-43\n1, Y, 24, Yaayol-43\n2, A, 22,
Aoliryi-43\n2, X, 24, Xeeeu-43\n3, A, 34, Aoliryi-43\n1, Y, 21,
Yoliryi-43\n1, Y, 21, Yoliryi-43\n3, Y, 22, Yeeeu-43\n2, X, 22,
Xoliryi-43\n2, X, 23, Xoliryi-43\n2, X, 14, Xoliryi-43\n3, Y, 22,
Yaayol-43\n3, X, 29, Xaayol-43\n2, X, 22, Xoliryi-43\n2, X, 43,
Xoliryi-43\n2, X, 44, Xoliryi-43\n3, Y, 22, Yoliryi-43\n3, X, 29,
Xoliryi-43"}>.
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you Giovanni, Sebastian.
2015-04-19 9:20 GMT+09:00 Giovanni P <fi...@gmail.com>:
> But I still don't see the need for the "phase" information. Its only use
> case is that, of when a pharmacist wants to know how many times and why a
> drug X was stopped? As a layman, I imagine that most of the time the drugs
> will be stopped because the disease which needed it has gone, right?
> Doesn't this breaks the case summing up all the times the drug was stopped,
> like in your example?
If I make a document per patient and each document includes all prescription
data, "phase" information seems to be generated within a map function.
I am now trying to make a test database.
The number of the reason a drug is stopped is at least 15, which includes
the case that the drug is continued but not prescribed,and of course
the case the drug is no more needed.
For example, analgesic X is prescribed 1000 times,of which 300 prescription
was "phase 1",700 was "phase 2",and 200 was "phase 3".
Of 200 "phase 3" cases, 150 cases patient said "the pain is over.so I don't
need this(this 'phase 3' information does not known until this patient goes to
pharmacy next time)." and 50 cases "This didn't work well, so I changed to
analgesic Z(phase 1)."
Likely, analgesic Y is prescribed 1500 times, of which 500 prescription
was "phase 1", 1000 was "phase 2" and 500 was "phase 3".
Of 500 "phase 3" cases 300 cases patient said "the pain is over, so I don't
need this." and 200 cases "switched to Z."
Since X worked for 150/200 cases(75%),and y worked for 300/500 cases(60%),
I should recommend X rather than Y(in fact I want to adjust the ratio with
patient's year,gender,etc.).
So the information of "phase 1" or "phase 2" is not so important here ,
and the bottleneck is to get the information of "this drug is stopped".
Of course if the patient never goes to the same hospital or pharmacy,
phase information stops at "2" or "3".
If a patient goes to another hospital or pharmacy, phase information is lost.
So the concept of "phase" may not fit to the use case and your suggestion
of "event" seems to be better than "phase".
> Also, what happens when a drug Y is being taken continuously through the
> whole life of the patient, then when he goes to some pharmacist, he does
> not even tell her about that drug, the pharmacist goes to the database and
> registers a new prescription, with another drug, not even mentioning the
> drug Y. This breaks the case for automatic calculation of phases.
>
> Now,you said that updating the phase under the key "optional_information"
> in the current prescription (before creating a new prescription) is
> inneficient because of two PUTs. Our first answer should be that you can
> use one POST to _bulk_docs and update and create the two prescriptions at
> the same time (now, if your documents are big, it is probably more
> efficient to issue two PUT to an _update handler, I don't know), so your
> approach is doable.
>
> Here are two ideas, however, that could be considered:
>
> 1. Forget the "phase" element of prescriptions and have just "events". One
> kind of event is the prescription. Each pharmacist creates a prescription
> and never changes it, it's an event. Or the pharmacist can create a
> "stopped" event, for when any drug is stopped, along with the date, reason
> etc. This is flexible, understandable, maps greatly to the real world facts
> allows you to do the third use case. You can have views that emit the
> drug/patient keys from all the events and then you'll know if it was used
> successfully till the end, stopped for some reason etc.
"One document for one event", documents are divided into immutable
prescription documents and mutable "stopped" documents, am I correct?
> 2. Add the "phase" in the next prescription instead of in the previous. In
> your example, this would be: at 4/1, Alice tells Bob she stopped the drug
> Q, Bob prescribes other drugs to Alice. Bob never touches the prescription
> "22222", he only adds to the prescription "33333" the drug Q with a phase
> 3, indicating that it is not being used anymore:
I am sorry I am not yet able to figure out the map function of this approach.
I will study this more carefully.
2015-04-20 4:50 GMT+09:00 Sebastian Rothbucher
<se...@googlemail.com>:
> Hi,
> I do like the Events idea that Giovanni suggested - and I think having a
> doc for each time the patient (Alice) visits a pharmacy (be it Bob or
> Carol) is a good idea as 80 or so MB per document sounds like a lot. Also I
> finally think I get the phase concept where 1=first-time, 2=continue,
> 3=discontinue) - which can indeed be stored at the time Alice visits the
> pharmacy I think
> Coming back to the very first question: I think including docs is neither
> related to the problem nor the solution. Including docs essentially allows
> shipping more documents out of Couch with one request to the view; it does
> not help in building the view or in correlating many events (what was
> prescribed, continued, discontinued when).
> I think taking a new and fresh perspective (e.g. on Giovanni's suggestion)
> could be valuable here...
I abort "including docs" for this purpose ,"map function referring two
document",
and I am okay to abort "phase" concept.
Should my question be "how to know the differences of two documents?"?
Giovanni's suggestion seems to be
(1) collect into one document and calculate the differences within a view
(2) make another document only when difference occurs
(3) update difference information as the past information
I have not thought of these ideas at all, and my understanding of the couchDB
or document database is getting cultivated(is this word correct?).
My development speed is very slow, but I will test the speed of (1) approach
first and report the result of it.
Sincerely yours, ken tashiro
Re: how to use an included document's key?
Posted by Sebastian Rothbucher <se...@googlemail.com>.
Hi,
I do like the Events idea that Giovanni suggested - and I think having a
doc for each time the patient (Alice) visits a pharmacy (be it Bob or
Carol) is a good idea as 80 or so MB per document sounds like a lot. Also I
finally think I get the phase concept where 1=first-time, 2=continue,
3=discontinue) - which can indeed be stored at the time Alice visits the
pharmacy I think
Coming back to the very first question: I think including docs is neither
related to the problem nor the solution. Including docs essentially allows
shipping more documents out of Couch with one request to the view; it does
not help in building the view or in correlating many events (what was
prescribed, continued, discontinued when).
I think taking a new and fresh perspective (e.g. on Giovanni's suggestion)
could be valuable here...
Good luck
Sebastian
On Sun, Apr 19, 2015 at 2:20 AM, Giovanni P <fi...@gmail.com> wrote:
> Ok, I'm still a little confused, but understand that all the things we
> suggested will not work for the third use case:
>
> > Third, at 5/1 another pharmacist Carol working at another pharmacy is
> > consulted by a prescriber that "I have prescribed my patient drug S but
> > this does not work well. So I am considering to switch drug S to drug Q
> or R.
> > Which drug do you recommend?" Then she ask the program and database
> > queries with the key "[phase, left-side n digits of drug Q corresponding
> to
> > the category of drug, drug name, the reason of drug being
> > stopped],value [ "1"].
> > She gets a list of drug Q or other drugs with the frequency of the
> stopping
> > (and optionally its reason).
> > Then she compares drug Q with R which is more suitable for Alice's case.
> > Carol also accesses to web server via browser.
>
> But I still don't see the need for the "phase" information. Its only use
> case is that, of when a pharmacist wants to know how many times and why a
> drug X was stopped? As a layman, I imagine that most of the time the drugs
> will be stopped because the disease which needed it has gone, right?
> Doesn't this breaks the case summing up all the times the drug was stopped,
> like in your example?
>
> Also, what happens when a drug Y is being taken continuously through the
> whole life of the patient, then when he goes to some pharmacist, he does
> not even tell her about that drug, the pharmacist goes to the database and
> registers a new prescription, with another drug, not even mentioning the
> drug Y. This breaks the case for automatic calculation of phases.
>
> Now,you said that updating the phase under the key "optional_information"
> in the current prescription (before creating a new prescription) is
> inneficient because of two PUTs. Our first answer should be that you can
> use one POST to _bulk_docs and update and create the two prescriptions at
> the same time (now, if your documents are big, it is probably more
> efficient to issue two PUT to an _update handler, I don't know), so your
> approach is doable.
>
> Here are two ideas, however, that could be considered:
>
> 1. Forget the "phase" element of prescriptions and have just "events". One
> kind of event is the prescription. Each pharmacist creates a prescription
> and never changes it, it's an event. Or the pharmacist can create a
> "stopped" event, for when any drug is stopped, along with the date, reason
> etc. This is flexible, understandable, maps greatly to the real world facts
> allows you to do the third use case. You can have views that emit the
> drug/patient keys from all the events and then you'll know if it was used
> successfully till the end, stopped for some reason etc.
>
> 2. Add the "phase" in the next prescription instead of in the previous. In
> your example, this would be: at 4/1, Alice tells Bob she stopped the drug
> Q, Bob prescribes other drugs to Alice. Bob never touches the prescription
> "22222", he only adds to the prescription "33333" the drug Q with a phase
> 3, indicating that it is not being used anymore:
>
> {
> "drugs":[
> {
> "name":"P",
> "drug id":"1234",
> "phase": 2
> },
> {
> "name":"R",
> "drug id":"2346",
> "phase": 1
> },
> {
> "name":"Q",
> "drug id":"2314",
> "phase": 3
> }
> ],
> ...
> }
>
> Why not?
>
> I'm probably missing something, but this is what I could think of.
>
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
Ok, I'm still a little confused, but understand that all the things we
suggested will not work for the third use case:
> Third, at 5/1 another pharmacist Carol working at another pharmacy is
> consulted by a prescriber that "I have prescribed my patient drug S but
> this does not work well. So I am considering to switch drug S to drug Q
or R.
> Which drug do you recommend?" Then she ask the program and database
> queries with the key "[phase, left-side n digits of drug Q corresponding
to
> the category of drug, drug name, the reason of drug being
> stopped],value [ "1"].
> She gets a list of drug Q or other drugs with the frequency of the
stopping
> (and optionally its reason).
> Then she compares drug Q with R which is more suitable for Alice's case.
> Carol also accesses to web server via browser.
But I still don't see the need for the "phase" information. Its only use
case is that, of when a pharmacist wants to know how many times and why a
drug X was stopped? As a layman, I imagine that most of the time the drugs
will be stopped because the disease which needed it has gone, right?
Doesn't this breaks the case summing up all the times the drug was stopped,
like in your example?
Also, what happens when a drug Y is being taken continuously through the
whole life of the patient, then when he goes to some pharmacist, he does
not even tell her about that drug, the pharmacist goes to the database and
registers a new prescription, with another drug, not even mentioning the
drug Y. This breaks the case for automatic calculation of phases.
Now,you said that updating the phase under the key "optional_information"
in the current prescription (before creating a new prescription) is
inneficient because of two PUTs. Our first answer should be that you can
use one POST to _bulk_docs and update and create the two prescriptions at
the same time (now, if your documents are big, it is probably more
efficient to issue two PUT to an _update handler, I don't know), so your
approach is doable.
Here are two ideas, however, that could be considered:
1. Forget the "phase" element of prescriptions and have just "events". One
kind of event is the prescription. Each pharmacist creates a prescription
and never changes it, it's an event. Or the pharmacist can create a
"stopped" event, for when any drug is stopped, along with the date, reason
etc. This is flexible, understandable, maps greatly to the real world facts
allows you to do the third use case. You can have views that emit the
drug/patient keys from all the events and then you'll know if it was used
successfully till the end, stopped for some reason etc.
2. Add the "phase" in the next prescription instead of in the previous. In
your example, this would be: at 4/1, Alice tells Bob she stopped the drug
Q, Bob prescribes other drugs to Alice. Bob never touches the prescription
"22222", he only adds to the prescription "33333" the drug Q with a phase
3, indicating that it is not being used anymore:
{
"drugs":[
{
"name":"P",
"drug id":"1234",
"phase": 2
},
{
"name":"R",
"drug id":"2346",
"phase": 1
},
{
"name":"Q",
"drug id":"2314",
"phase": 3
}
],
...
}
Why not?
I'm probably missing something, but this is what I could think of.
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you Sebastian,Giovanni.
I am afraid that I am posting an out of place question here with
inaccurate english
and annoying you.
2015-04-18 5:04 GMT+09:00 Sebastian Rothbucher
<se...@googlemail.com>:
> Hi Ken,
>
> I'm with Giovanni here - I think we still puzzle to get the actual use
> case. Is it like the guy working behind the parmacy counter is to see which
> drugs to hand out to a patient today based on the patient's prescriptions
> or what exactly is the case? Maybe we can all be of more help as soon as we
> understand what the analysis is supposed to yield (without yet jumping to
> conclusions about implementation)...
For example, at 3/1 patient Alice had a prescription filled which included drug
P and Q by a pharmacist Bob. The document id corresponding to this
prescription is "11111".
At 4/1 Alice has a prescription filled which includes drug P and R by Bob.
The document id is "22222".
The phase of P ,Q, R will be "2", "3","1" respectively.
Now I suppose three major use cases.
At first, default use case.
All prescription data is automatically uploaded to couchDB at the time of
Bob processing the prescription electrically. I want to add phase information
here.
Second, at 4/1 when Bob dispenses the drugs to the patient, he asks to
Alice the reason ("she experienced adversereaction", "switched to cheeper
drug", "capsule is too large", etc.).
Bob updates the document "22222 " by adding the reason why drug Q
was stopped.
Bob accesses to web server via browser and does not see
couchDB(cloudant) directly.
This action is left to Bob, and he can update information at 4/2 or later.
Third, at 5/1 another pharmacist Carol working at another pharmacy is
consulted by a prescriber that "I have prescribed my patient drug S but
this does not work well. So I am considering to switch drug S to drug Q or R.
Which drug do you recommend?" Then she ask the program and database
queries with the key "[phase, left-side n digits of drug Q corresponding to
the category of drug, drug name, the reason of drug being
stopped],value [ "1"].
She gets a list of drug Q or other drugs with the frequency of the stopping
(and optionally its reason).
Then she compares drug Q with R which is more suitable for Alice's case.
Carol also accesses to web server via browser.
2015-04-17 21:29 GMT+09:00 Giovanni P <fi...@gmail.com>:
> Sorry, but I still don't get what are the application requirements.
>
> Each prescription is a document, right? Each prescription document has
> {
> "prescriber": "the id of the prescriber",
> "patient": "the id of the patient",
> "date": "the date",
> "drugs": [
> "an array of the ids",
> "of all the drugs",
> "in this prescription"
> ]
> }
>
> Is that right?
Yes, I have thought of "one document per one prescription".
Actually each prescription document has more than 200 keys, but essentially
you are right.
Drug information is a list of dictionaries.
Now my program adds "optional information" to the document at 4/1.
{
"_id":"22222",
"_rev":"1-xxxxxx",
"patient_information": { }
"prescriber_information":{ },
"pharmacy_information":{"name":"Bob" ,etc. },
"date":"2015-4-1",
"drugs":[
{
"name":"P",
"drug id":"1234",
etc.
},
{
"name":"R",
"drug id":"2346",
etc.
}
],
"optional_information" {
"1234": {
"phase":2,
"name":"P"
},
"2345": {
"phase":3,
"name":"Q"
"reason":["adverse reaction"]
},
"2346": {
"phase":1,
"name":"R"
},
}:
}
> But you also need the last prescription done by the same prescriber who is
> consulting the database at the moment, regardless of it being the last
> prescription for that patient or not?
>
> What is stopping you from getting all the previous (or, say, the last 20
> previous) prescriptions for each patient in the same query and
> showing/using/calculating based on that data?
Each time pharmacist Bob and Carol access the database , phase
information is used.
I understand that phase information can be made with three ways:
1. local browser generates phase information each time Bob or Carol needs it.
2. web server generates phase information each time client requests.
3. couchDB stores phase information permanently.
(4. couchDB generates phase information each time web server requests.
This is impossible)
> Also important: it is impossible to link documents, each document is an
> island. It can be broken into various different keys in a view (it can emit
> various keys from one view), but it cannot be joined or directly referenced
> by another. Update functions act on individual documents, I only
> recommended using those when I suggested that you kept only one document
> for each patient with all its prescriptions inside.
I have not at all thought of "one document for one patient".
It happens that patient Alice in pharmacy X is the same person as patient
Cooper in pharmacy Y. But all individual is planned to have a common
social security number within a year or two, so "one document for one social
security number" seems to be more attractive than "one document per
one prescription".
My prescription document has 36kb in average. Patient Alice's document size
will be less than 36 kb/prescription x 10 prescriptions/month x
12month x 20years =
86400kb. This size seems not too be large.
I will test this document structure more deeply.
Thank you again, Giovanni.
ken tashiro
Re: how to use an included document's key?
Posted by Sebastian Rothbucher <se...@googlemail.com>.
Hi Ken,
I'm with Giovanni here - I think we still puzzle to get the actual use
case. Is it like the guy working behind the parmacy counter is to see which
drugs to hand out to a patient today based on the patient's prescriptions
or what exactly is the case? Maybe we can all be of more help as soon as we
understand what the analysis is supposed to yield (without yet jumping to
conclusions about implementation)...
Cheers
Sebastian
On Fri, Apr 17, 2015 at 2:29 PM, Giovanni P <fi...@gmail.com> wrote:
> Sorry, but I still don't get what are the application requirements.
>
> Each prescription is a document, right? Each prescription document has
> {
> "prescriber": "the id of the prescriber",
> "patient": "the id of the patient",
> "date": "the date",
> "drugs": [
> "an array of the ids",
> "of all the drugs",
> "in this prescription"
> ]
> }
>
> Is that right?
>
> You need the phase of each drug, which is only a number that is
> 1 if drug is in the last prescription, but not in the second last;
> 2 if drug is in the the last and second last prescriptions;
> 3 if drug is in the last prescription but not in the second last.
>
> Is that right?
>
> But you also need the last prescription done by the same prescriber who is
> consulting the database at the moment, regardless of it being the last
> prescription for that patient or not?
>
> What is stopping you from getting all the previous (or, say, the last 20
> previous) prescriptions for each patient in the same query and
> showing/using/calculating based on that data?
>
> Also important: it is impossible to link documents, each document is an
> island. It can be broken into various different keys in a view (it can emit
> various keys from one view), but it cannot be joined or directly referenced
> by another. Update functions act on individual documents, I only
> recommended using those when I suggested that you kept only one document
> for each patient with all its prescriptions inside.
>
> Again, sorry for my inability to comprehend.
>
> On Fri, Apr 17, 2015 at 6:19 AM, rara7020 . <
> matthieu.rakotojaona@gmail.com>
> wrote:
>
> > Hey Ken,
> >
> > You need the phase in your application, but do you need to store it in
> > the database, knowing that it can always be extracted from the data ?
> >
> > An other solution (I think that's what Giovanni points out) is to
> > _not_ put phases in the prescription:
> >
> > - When you have a new prescription, just write it to the database
> >
> > - To know the current phase, retrieve the 2 last doc for each
> > prescriber (you can use your second query here). Since you already put
> > the current prescription, this will give you the current and the last,
> > and then you diff in your application. For each drug you know if it
> > was there in the previous prescription or not, so you can derive phase
> > for each drug. I'm not 100% sure, but you could even build a _reduce
> > that creates the result for you here.
> >
> > Now with this you may have a problem of consistency: if one of your
> > databases has the 2 last documents, but another database isn't
> > perfectly synced, both databases may not give you the same output.
> > This is kind of expected since your phases span multiple documents. If
> > you have the last prescription id in the current prescription though,
> > you at least know if you lack any of them (but you can't do anything
> > without first syncing)
> >
> >
> > On Fri, Apr 17, 2015 at 4:45 AM, ken tashiro <presidenttashiro@gmail.com
> >
> > wrote:
> > > Thank you again, Giovanni.
> > >
> > >> I don't know if I understood it correctly. Why would you need two
> > queries
> > >> for fetching the current prescription and the last prescription? You
> > can do
> > >> limit=2 and get the current and the last prescriptions at the same
> time.
> > >
> > > I am sorry for my complicated explanation.
> > >
> > > At the time of these two queries,current prescription data is not yet
> > > uploaded to couchDB,so If I do limit=1 then get the last prescription
> > data.
> > >
> > > If the current prescription has N drugs prescribed,first query gets at
> > most
> > > N "last prescriptions" that include each drug prescribed in the
> current
> > > prescription regardless of who prescribed it.
> > > So, key is [pharmacy_code,patient_code,drug_code,date],
> > > value is phase,
> > >
> > > Second query gets at most one "last prescription" which is prescribed
> > > by the same prescriber.
> > > So, key is [pharmacy_code,patient_code,prescriber_code,date],
> > > value is [drug_code],
> > >
> > > I thought these queries could be united using reduce function and
> > different
> > > key levels,but could not find the way.
> > >
> > >> For example. Then you can query this view with
> > >> ?include_docs=true&descending=true and get all the data at once.
> > >
> > > By adding at most (N + 1) document ids of "the last prescription
> > > ('last' has two meanings)" to the current prescription data which is
> > > not yet uploaded and setting "?include_docs=true" instead of
> > > adding "optional_information" , I want to use the content of linked
> > > document within a map function, but it is impossible.Only client side
> > > program which gets the query result can use linked documents?
> > >
> > > You indicated me to PUT the current prescription data without any
> > > optional data, then using update functions add optional data to this
> > > prescription data.
> > > Am I correct?
> > >
> > > ken tashiro
> >
> >
> >
> > --
> > Matthieu RAKOTOJAONA
> >
>
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
Sorry, but I still don't get what are the application requirements.
Each prescription is a document, right? Each prescription document has
{
"prescriber": "the id of the prescriber",
"patient": "the id of the patient",
"date": "the date",
"drugs": [
"an array of the ids",
"of all the drugs",
"in this prescription"
]
}
Is that right?
You need the phase of each drug, which is only a number that is
1 if drug is in the last prescription, but not in the second last;
2 if drug is in the the last and second last prescriptions;
3 if drug is in the last prescription but not in the second last.
Is that right?
But you also need the last prescription done by the same prescriber who is
consulting the database at the moment, regardless of it being the last
prescription for that patient or not?
What is stopping you from getting all the previous (or, say, the last 20
previous) prescriptions for each patient in the same query and
showing/using/calculating based on that data?
Also important: it is impossible to link documents, each document is an
island. It can be broken into various different keys in a view (it can emit
various keys from one view), but it cannot be joined or directly referenced
by another. Update functions act on individual documents, I only
recommended using those when I suggested that you kept only one document
for each patient with all its prescriptions inside.
Again, sorry for my inability to comprehend.
On Fri, Apr 17, 2015 at 6:19 AM, rara7020 . <ma...@gmail.com>
wrote:
> Hey Ken,
>
> You need the phase in your application, but do you need to store it in
> the database, knowing that it can always be extracted from the data ?
>
> An other solution (I think that's what Giovanni points out) is to
> _not_ put phases in the prescription:
>
> - When you have a new prescription, just write it to the database
>
> - To know the current phase, retrieve the 2 last doc for each
> prescriber (you can use your second query here). Since you already put
> the current prescription, this will give you the current and the last,
> and then you diff in your application. For each drug you know if it
> was there in the previous prescription or not, so you can derive phase
> for each drug. I'm not 100% sure, but you could even build a _reduce
> that creates the result for you here.
>
> Now with this you may have a problem of consistency: if one of your
> databases has the 2 last documents, but another database isn't
> perfectly synced, both databases may not give you the same output.
> This is kind of expected since your phases span multiple documents. If
> you have the last prescription id in the current prescription though,
> you at least know if you lack any of them (but you can't do anything
> without first syncing)
>
>
> On Fri, Apr 17, 2015 at 4:45 AM, ken tashiro <pr...@gmail.com>
> wrote:
> > Thank you again, Giovanni.
> >
> >> I don't know if I understood it correctly. Why would you need two
> queries
> >> for fetching the current prescription and the last prescription? You
> can do
> >> limit=2 and get the current and the last prescriptions at the same time.
> >
> > I am sorry for my complicated explanation.
> >
> > At the time of these two queries,current prescription data is not yet
> > uploaded to couchDB,so If I do limit=1 then get the last prescription
> data.
> >
> > If the current prescription has N drugs prescribed,first query gets at
> most
> > N "last prescriptions" that include each drug prescribed in the current
> > prescription regardless of who prescribed it.
> > So, key is [pharmacy_code,patient_code,drug_code,date],
> > value is phase,
> >
> > Second query gets at most one "last prescription" which is prescribed
> > by the same prescriber.
> > So, key is [pharmacy_code,patient_code,prescriber_code,date],
> > value is [drug_code],
> >
> > I thought these queries could be united using reduce function and
> different
> > key levels,but could not find the way.
> >
> >> For example. Then you can query this view with
> >> ?include_docs=true&descending=true and get all the data at once.
> >
> > By adding at most (N + 1) document ids of "the last prescription
> > ('last' has two meanings)" to the current prescription data which is
> > not yet uploaded and setting "?include_docs=true" instead of
> > adding "optional_information" , I want to use the content of linked
> > document within a map function, but it is impossible.Only client side
> > program which gets the query result can use linked documents?
> >
> > You indicated me to PUT the current prescription data without any
> > optional data, then using update functions add optional data to this
> > prescription data.
> > Am I correct?
> >
> > ken tashiro
>
>
>
> --
> Matthieu RAKOTOJAONA
>
Re: how to use an included document's key?
Posted by "rara7020 ." <ma...@gmail.com>.
Hey Ken,
You need the phase in your application, but do you need to store it in
the database, knowing that it can always be extracted from the data ?
An other solution (I think that's what Giovanni points out) is to
_not_ put phases in the prescription:
- When you have a new prescription, just write it to the database
- To know the current phase, retrieve the 2 last doc for each
prescriber (you can use your second query here). Since you already put
the current prescription, this will give you the current and the last,
and then you diff in your application. For each drug you know if it
was there in the previous prescription or not, so you can derive phase
for each drug. I'm not 100% sure, but you could even build a _reduce
that creates the result for you here.
Now with this you may have a problem of consistency: if one of your
databases has the 2 last documents, but another database isn't
perfectly synced, both databases may not give you the same output.
This is kind of expected since your phases span multiple documents. If
you have the last prescription id in the current prescription though,
you at least know if you lack any of them (but you can't do anything
without first syncing)
On Fri, Apr 17, 2015 at 4:45 AM, ken tashiro <pr...@gmail.com> wrote:
> Thank you again, Giovanni.
>
>> I don't know if I understood it correctly. Why would you need two queries
>> for fetching the current prescription and the last prescription? You can do
>> limit=2 and get the current and the last prescriptions at the same time.
>
> I am sorry for my complicated explanation.
>
> At the time of these two queries,current prescription data is not yet
> uploaded to couchDB,so If I do limit=1 then get the last prescription data.
>
> If the current prescription has N drugs prescribed,first query gets at most
> N "last prescriptions" that include each drug prescribed in the current
> prescription regardless of who prescribed it.
> So, key is [pharmacy_code,patient_code,drug_code,date],
> value is phase,
>
> Second query gets at most one "last prescription" which is prescribed
> by the same prescriber.
> So, key is [pharmacy_code,patient_code,prescriber_code,date],
> value is [drug_code],
>
> I thought these queries could be united using reduce function and different
> key levels,but could not find the way.
>
>> For example. Then you can query this view with
>> ?include_docs=true&descending=true and get all the data at once.
>
> By adding at most (N + 1) document ids of "the last prescription
> ('last' has two meanings)" to the current prescription data which is
> not yet uploaded and setting "?include_docs=true" instead of
> adding "optional_information" , I want to use the content of linked
> document within a map function, but it is impossible.Only client side
> program which gets the query result can use linked documents?
>
> You indicated me to PUT the current prescription data without any
> optional data, then using update functions add optional data to this
> prescription data.
> Am I correct?
>
> ken tashiro
--
Matthieu RAKOTOJAONA
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you again, Giovanni.
> I don't know if I understood it correctly. Why would you need two queries
> for fetching the current prescription and the last prescription? You can do
> limit=2 and get the current and the last prescriptions at the same time.
I am sorry for my complicated explanation.
At the time of these two queries,current prescription data is not yet
uploaded to couchDB,so If I do limit=1 then get the last prescription data.
If the current prescription has N drugs prescribed,first query gets at most
N "last prescriptions" that include each drug prescribed in the current
prescription regardless of who prescribed it.
So, key is [pharmacy_code,patient_code,drug_code,date],
value is phase,
Second query gets at most one "last prescription" which is prescribed
by the same prescriber.
So, key is [pharmacy_code,patient_code,prescriber_code,date],
value is [drug_code],
I thought these queries could be united using reduce function and different
key levels,but could not find the way.
> For example. Then you can query this view with
> ?include_docs=true&descending=true and get all the data at once.
By adding at most (N + 1) document ids of "the last prescription
('last' has two meanings)" to the current prescription data which is
not yet uploaded and setting "?include_docs=true" instead of
adding "optional_information" , I want to use the content of linked
document within a map function, but it is impossible.Only client side
program which gets the query result can use linked documents?
You indicated me to PUT the current prescription data without any
optional data, then using update functions add optional data to this
prescription data.
Am I correct?
ken tashiro
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
I don't know if I understood it correctly. Why would you need two queries
for fetching the current prescription and the last prescription? You can do
limit=2 and get the current and the last prescriptions at the same time.
But I suppose that your problem with the 2 queries is that you're doing one
query for fetching the patient document, with his basic information, and
then a query to check if it has prescriptions and what they are.
If so, you only need a view that emits
[patient_id, 1] -- patient document
[patient_id, 0, prescription_date] -- prescription document
[patient_id, 0, prescription_date] -- prescription document
[patient_id, 0, prescription_date] -- prescription document
[patient_id, 0, prescription_date] -- prescription document
For example. Then you can query this view with
?include_docs=true&descending=true and get all the data at once.
Sorry if I misunderstood your problem.
On Thu, Apr 16, 2015 at 3:17 AM, ken tashiro <pr...@gmail.com>
wrote:
> Thank you again, Giovanni.
>
> > Depending on what exactly you are doing, you could perhaps add
> everything as
> > one document, using update functions to prevent the roundtrip?
>
> I am a pharmacist in Japan, and trying to make a database of prescription.
> In Japan, almost 100% of all prescriptions are electrically processed with
> a common data format.But this format is revised every two years,so I chose
> a schema-free database.
>
> Since Japan has experienced several disasters, couchDB seems
> to be suitable for storing patient medical records.(when internet access is
> unavailable, store in a local couchDB, when available, replicate to cloud.)
>
> I want to manage information about the prescription such that
> "this drug is newly prescribed(phase=1)",
> "this drug is used continuously(phase=2)"
> or "this drug is NOT prescribed today but prescribed in the last
> prescription(phase=3)"
> and add to prescription data.
>
> So I made two map functions.
> First,
> key is [pharmacy_code,patient_code,drug_code,date],
> value is phase,
> and descending=true and limit=1,
> If prescription is submitted, my program does this query for each drug.
> If phase =1 then add {"optional_information": {drug_code: {"phase":"2"} } }
> If phase =2 then add {"optional_information": {drug_code: {"phase":"2"} } }
> If phase =3 then add {"optional_information": {drug_code: {"phase":"1"} } }
> If result = null then add {"optional_information": {drug_code:
> {"phase":"1"} } }
>
> Next,
> key is [pharmacy_code,patient_code,prescriber_code,date],
> value is [drug_code],
> and descending=true and limit=1,
> If prescription is submitted, my program does this query once.
> If there is a drug prescribed in the last prescription but not in the
> current prescription, then add {"optional_information": {drug_code:
> {"phase":"3"} } }
>
> Now if I add the last prescription's document id in the current
> prescription's
> document (this needs one query anyway), I wonder if I can get the list of
> drugs
> in the last prescription without adding "optional_information",but it
> is impossible,
> instead I should learn using update function, am I correct?
>
> ken tashiro
>
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you again, Giovanni.
> Depending on what exactly you are doing, you could perhaps add everything as
> one document, using update functions to prevent the roundtrip?
I am a pharmacist in Japan, and trying to make a database of prescription.
In Japan, almost 100% of all prescriptions are electrically processed with
a common data format.But this format is revised every two years,so I chose
a schema-free database.
Since Japan has experienced several disasters, couchDB seems
to be suitable for storing patient medical records.(when internet access is
unavailable, store in a local couchDB, when available, replicate to cloud.)
I want to manage information about the prescription such that
"this drug is newly prescribed(phase=1)",
"this drug is used continuously(phase=2)"
or "this drug is NOT prescribed today but prescribed in the last
prescription(phase=3)"
and add to prescription data.
So I made two map functions.
First,
key is [pharmacy_code,patient_code,drug_code,date],
value is phase,
and descending=true and limit=1,
If prescription is submitted, my program does this query for each drug.
If phase =1 then add {"optional_information": {drug_code: {"phase":"2"} } }
If phase =2 then add {"optional_information": {drug_code: {"phase":"2"} } }
If phase =3 then add {"optional_information": {drug_code: {"phase":"1"} } }
If result = null then add {"optional_information": {drug_code:
{"phase":"1"} } }
Next,
key is [pharmacy_code,patient_code,prescriber_code,date],
value is [drug_code],
and descending=true and limit=1,
If prescription is submitted, my program does this query once.
If there is a drug prescribed in the last prescription but not in the
current prescription, then add {"optional_information": {drug_code:
{"phase":"3"} } }
Now if I add the last prescription's document id in the current prescription's
document (this needs one query anyway), I wonder if I can get the list of drugs
in the last prescription without adding "optional_information",but it
is impossible,
instead I should learn using update function, am I correct?
ken tashiro
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
Depending on what exactly you are doing, you could perhaps add everything
as one document, using update functions to prevent the roundtrip?
On Wed, Apr 15, 2015 at 1:09 PM, ken tashiro <pr...@gmail.com>
wrote:
> Thank you, Giovanni.
>
> > You can't. Each document only knows about itself. But there is probably
> > another way of accomplishing what you want with CouchDB.
>
> In my current application, just before local program uploads document
> "33333"
> it searches couchDB and knows 'the ancestor of this document "33333" is
> "22222" and its value is "hello" ' , then add {"its ancestor
> value":"hello"}
> to document "33333" , then finally upload the document "33333".
>
> So, to PUT one document,local program communicates with couchDB
> twice and I feel it inefficient.
> But I understand this GET and PUT is necessary.
>
> I'm sorry for my poor english.
>
> ken tashiro
>
Re: how to use an included document's key?
Posted by ken tashiro <pr...@gmail.com>.
Thank you, Giovanni.
> You can't. Each document only knows about itself. But there is probably
> another way of accomplishing what you want with CouchDB.
In my current application, just before local program uploads document "33333"
it searches couchDB and knows 'the ancestor of this document "33333" is
"22222" and its value is "hello" ' , then add {"its ancestor value":"hello"}
to document "33333" , then finally upload the document "33333".
So, to PUT one document,local program communicates with couchDB
twice and I feel it inefficient.
But I understand this GET and PUT is necessary.
I'm sorry for my poor english.
ken tashiro
Re: how to use an included document's key?
Posted by Giovanni P <fi...@gmail.com>.
You can't. Each document only knows about itself. But there is probably
another way of accomplishing what you want with CouchDB.
On Wed, Apr 15, 2015 at 6:55 AM, ken tashiro <pr...@gmail.com>
wrote:
> Hi,
>
> I have a question. Suppose documents are
> [
> { "_id": "11111" },
> { "_id": "22222", "ancestors": ["11111"], "value": "hello" },
> { "_id": "33333", "ancestors": ["22222","11111"], "value": "world" }
> ]
> like
>
> http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views#Linked_documents
> and "include_docs=true".
>
> I want to make a map function like
> function(doc) {
> if (doc.ancestors) {
> for (var i in doc.ancestors) {
> if ( doc.value === 'world' AND ' value of ancestor is "hello" ' )
> {
> emit (doc._id,ancestor's id);
> }
> }
> }
> }
> and get {"key":"33333",value:"22222"}.
>
> My question is how can I use an included document and know
> "value of ancestor" ?
>
> Thank you.
>
> ken tashiro
>