Documento XPath la ricerca con di Mark Logic Java API di ricerca vs API XQuery/XSLT

Question

Ho la seguente interrogazione Mark Logic che, quando eseguito nella console di query, mi permette di recuperare che hanno privilegi di amministratore di mio utente del sistema:

xquery version "1.0-ml"; 
import schema namespace bfa="http://bitfood.org/auth" at "schema/auth/bitfood-auth.xsd"; 
cts:search(/bfa:AppUser[bfa:appAccess/@appRole = "ROLE_SYS_ADMIN"], cts:and-query(())) 

Perdonate la mia ignoranza, ma è possibile implementare questa query usando solo l'API del client Java?

So che potrei utilizzare la query non elaborata tramite XCC ma sto cercando di evitarlo il più possibile.

Sto scavando attraverso la documentazione dell'API del client Java che, sfortunatamente, si occupa brevemente di altri metodi di ricerca e non ho trovato nulla che suggerisse che ciò è possibile.

UPDATE 1: Ragazzi, penso di aver raggiunto uno showstopper qui.

In base a this question, le funzionalità di creazione delle opzioni di query dell'API del client Java sono contrassegnate come deprecate.

@ hehennum suggerisce un'alternativa che utilizza le opzioni di query XML o JSON. Tuttavia, tale interrogazione specifiche di opzione sono still essentially defined as raw Strings in the code:

String xmlOptions = 
    "<search:options "+ 
     "xmlns:search='http://marklogic.com/appservices/search'>"+ 
     "<search:constraint name='industry'>"+ 
     "<search:value>"+ 
      "<search:element name='industry' ns=''/>"+ 
     "</search:value>"+ 
     "</search:constraint>"+ 
    "</search:options>"; 

Certo, potrei usare JAXB, JDOM, file o qualche altro strumento per creare l'XML, ma la mia opinione personale è che siamo ancora ricorrere a storing queries in resource files in the code, che è non è una cosa negativa di per sé, ma senza un'attenta considerazione potrebbe portare a incubi di manutenzione del codice.

Inoltre, il fatto che queste opzioni debbano essere mantenute tramite REST sul server introduce un ulteriore livello di potenziali problemi nel caso in cui ciò sia obbligatorio poiché le opzioni potrebbero necessitare di essere sincronizzate con ogni istanza di database che deve funzionare con una base di codice.

Quindi, se gli sviluppatori di Marklogic sono in ascolto, penso che l'API del client Java non sia così matura o documentata come mi aspettavo che fosse.

Ho due opzioni finora:

1) ho potuto hardcode mie domande XCC nei file di stringa e tenta di utilizzare segnaposto dei parametri per inserire i dati di cui ho bisogno e recuperare tramite una sessione di XCC. O.

2) Vedere se ci sono dei file XSD per il http://marklogic.com/appservices/search spazio dei nomi e creare oggetti JAXB statici da loro al fine di costruire una sorta di "criteri" classi a la Hibernate o QueryDSL che, purtroppo devo dire, già supporta un certo livello di Interrogazione di MongoDB.

I ragazzi, in realtà, apportano una sorta di fluenti servizi di interrogazione come QueryDSL a Marklogic e si liberano di questo Rube Goldberg querying machine.

Aggiornamento 2: Sembra che questo indirizzo possa essere risolto in ML7. Non vedere l'ora di.

Grazie!

Answer 1

Background: l'API Java è uno strato sulle API REST è uno strato sul Search API è uno strato sulla CTS: ricerca

È possibile esprimere questa query nella Search API.

• usare un'espressione ricercabile per il primo parametro nelle opzioni di query http://docs.marklogic.com/guide/search-dev/search-api#id_43671

• utilizzare una vuota e query per la query strutturata http://docs.marklogic.com/guide/search-dev/structured-query#id_83674

Utilizzando l'API di Java, è possibile cercare utilizzando le opzioni di query e la query strutturata come RawCombinedQueryDefinition.

Detto questo, si può solo anche cercare un elemento-query su BFA: appuser contenente una query vincolo valore BFA: appAccess/@ appRole di "ROLE_SYS_ADMIN"

Mentre XPath può essere conveniente, è un buona idea per diventare conversant nelle espressioni di query per comprendere la piena potenza e flessibilità del database.

Update 1:

Un paio di cose da considerare:

• una query nel Search API ha due parti: la query (espresso sia con stile Google stringa di ricerca o con JSON o ricerca strutturata XML) e le opzioni di query. StructuredQueryBuilder crea una ricerca strutturata. QueryOptionsBuilder ha creato solo le opzioni di query.

• In ML 6.0-3, l'API REST ha introdotto il supporto per la ricerca combinata, che fornisce entrambe le parti in una singola richiesta. L'API Java ha aggiunto il supporto per tali richieste attraverso la classe RawCombinedQueryDefinition.

• ML7 sta espandendo la ricerca strutturata per ridurre o eliminare la necessità di opzioni di query con ricerca strutturata. StructuredQueryBuilder è migliorato in ML7 per supportare le nuove funzionalità della ricerca strutturata. In ML7, sarai in grado di scrivere la tua query di esempio sopra interamente in StructuredQueryBuilder senza alcuna necessità di opzioni di query.

• Quando abbiamo confrontato il codice con le opzioni di query con QueryOptionsBuilder e con JDOM o XOM, è stato difficile vedere molti vantaggi LOC nel builder.

• Non è necessario specificare le opzioni di query con hardcode in una stringa. Per la separazione dei dubbi, è possibile leggere le opzioni di query JSON o XML da un file o da molte altre fonti. (Vedere le implementazioni dell'interfaccia marker http://docs.marklogic.com/javadoc/client/com/marklogic/client/io/marker/QueryOptionsReadHandle.html.)

• Le opzioni di query forniscono una dichiarazione anziché un codice eseguibile. Il parallelo sarebbe con i file di configurazione di Spring piuttosto che con i file SPL.

BTW, mentre JAXB è grande per i disegni provenienti in classi Java, JAXB può essere molto doloroso per i disegni di provenienza in uno schema XML complesso. Lo schema di ricerca sfrutta le potenti funzionalità degli schemi XML. Quando abbiamo esplorato questa rotta, abbiamo concluso che JAXB non avrebbe aiutato a fornire un'interfaccia per le opzioni di query.