Qual è il valore massimo per una chiave CouchDB composta?

Question

sto usando quello che sembra essere un trucco comune per la creazione di una vista join:

// a Customer has many Orders; show them together in one view: 
function(doc) { 
    if (doc.Type == "customer") { 
    emit([doc._id, 0], doc); 
    } else if (doc.Type == "order") { 
    emit([doc.customer_id, 1], doc); 
    } 
} 

So che posso utilizzare la seguente query per ottenere un unico customer e tutti i relativi Order s:

?startkey=["some_customer_id"]&endkey=["some_customer_id", 2] 

Ma ora ho legato la mia domanda molto strettamente al mio codice di vista. C'è un valore che posso mettere dove ho messo il mio "2" per dire più chiaramente, "Voglio tutto legato a questo cliente"? Penso che ho visto

?startkey=["some_customer_id"]&endkey=["some_customer_id", {}] 

Ma io non sono sicuro che sia {}certo per ordinare dopo tutto il resto.

Credito a cmlenz per il metodo di join.

ulteriori chiarimenti alla CouchDB wiki page on collation:

La query startkey=["foo"]&endkey=["foo",{}] corrisponderà maggior chiavi dell'array con "foo" nel primo elemento, come ["foo","bar"] e ["foo",["bar","baz"]]. Tuttavia esso non corrisponde ["foo",{"an":"object"}]

Così {} è ritardo nell'ordinamento, ma sicuramente non ultima .

Answer 1

Invece di cercare di trovare il maggior possibile valore per la seconda elemento la propria chiave di array, vorrei suggerire invece cercando di trovare il almeno possibile valore maggiore rispetto alla prima : ?startkey=["some_customer_id"]&endkey=["some_customer_id\u0000"]&inclusive_end=false.

Answer 2

CouchDB è scritto principalmente in Erlang. Non penso che ci sarebbe un limite superiore per una dimensione di stringhe composte/tuple di chiavi composite diverse dalle risorse di sistema (ad esempio una chiave così lunga che ha usato tutta la memoria disponibile). I limiti della scalabilità di CouchDB sono sconosciuti secondo il sito CouchDB. Immagino che potresti continuare ad aggiungere campi in un'enorme chiave primaria composita e l'unica cosa che ti impedirebbe di trovare risorse di sistema o limiti rigidi come le dimensioni massime integer nell'architettura di destinazione.

Poiché CouchDB memorizza tutto utilizzando JSON, è probabilmente limitato ai valori numerici più grandi dallo standard ECMAScript. Tutti i numeri in JavaScript sono memorizzati come IEEE 754 a virgola mobile in virgola mobile. Credo che il doppio a 64 bit possa rappresentare valori compresi tra - 5e-324 e +17979931348623157e + 308.

Answer 3

Sembra che sarebbe bello avere una funzione in cui endKey potrebbe essere inclusivo anziché esclusivo.

Answer 4

Questo dovrebbe fare il trucco:

?startkey=["some_customer_id"]&endkey=["some_customer_id", "\uFFFF"] 

Ciò dovrebbe includere tutto ciò che inizia con un carattere meno di \ uFFFF (tutti i caratteri Unicode)

• http://wiki.apache.org/couchdb/View_collation

Answer 5

ho due pensieri.

Usa timestamp

Invece di usare semplici 0 e 1 per il loro comportamento fascicolazione, utilizzare un timestamp che il record è stato creato (ammesso che sono parte integrante della documentazione) alla [doc._id, doc.created_at]. Quindi puoi interrogare la tua vista con una startkey di data sufficientemente anticipata (probabilmente l'epoca probabilmente funzionerà), e una endkey di "now", ad esempio date +%s. Quel range chiave dovrebbe sempre includere tutto, e ha il vantaggio aggiuntivo di raccogliere per data, che è probabilmente quello che vuoi comunque.

o, solo che non ti preoccupare

si può solo indice dal customer_id e nulla più. Questo avrebbe il vantaggio di poter interrogare usando solo key=<customer_id>. Certo, i record non verranno raccolti quando torneranno, ma è un problema per la tua applicazione? A meno che non ti aspetti un sacco di record, probabilmente sarebbe banale semplicemente estrarre il record del cliente dall'elenco una volta che hai recuperato i dati dalla tua applicazione.

Per esempio in Ruby:

customer_records = records.delete_if { |record| record.type == "customer" }

In ogni modo, i timestamp è probabilmente la risposta più attraente per il vostro caso.