Mormot 2 esempio Mongodb

[slapshot]

Ciao a tutti, sto riprendendo il progetto Mormot che avevo spulciato qualche anno fa. Ora mi trovo nel bel mezzo del salto, da 1 a 2. Esempi ce ne sono pochi, quelli di Mormot 1 non compilano sempre e definire la curva di apprendimento ripida è un eufemismo. Qualcuno di voi lo hai mai usato verso mongodb?

Vorrei fare qualcosa di molto semplice, ovvero creare un oggetto da una generica classe TPerson e salvarlo nel db. Stralci di esempio ne avete ? Prima di scrivere nel forum ufficiale che è generalmente per utenti avanzati.

Grazie

[nomorelogic]

ciao
mormot2 ci ho guardato in passato, e mi sono presto reso conto che si tratta di un patrimonio per gli amanti del pascal
purtroppo la curva di apprendimento, come dici tu, è ripida e se ti metti ad usarlo, poi conviene rimanere nel suo universo

con l'occasione segnalo il loro forum che è il seguente
https://synopse.info/forum/viewforum.php?id=24

mentre degli esempi per mongo (ma anche per altro) li puoi trovare qui
https://github.com/synopse/mORMot2/blob/master/ex/README.md

se dovessi approfondire, qualche articolo per approcciare a questo framework sarebbe graditissimo da tutti penso

buon lavoro

[slapshot]

mentre degli esempi per mongo (ma anche per altro) li puoi trovare qui
https://github.com/synopse/mORMot2/blob/master/ex/README.md

grazie nomorelogic, in effetti stavo guardando proprio quel test. Ma ripeto cercavo un esempio molto più semplice, ovvero il mapping della classe al db, la creazione di un oggetto, la persistenza al db json e poi magari recuperarlo. Quel codice è troppo complesso per imparare ad usare il framework, poi è pieno di ifdef che lo rendono discretamente illeggibile. L'AI mi aiuta un pò ma, alla fine della fiera, dimostra di essere non troppo I . Proverò a scrivere sui loro forum ufficiali, come consigli.

Mi piacerebbe approfondire, per quanto offre credo sia una libreria davvero super completa. Anche le performance sembrano egregie.

Grazie, se riuscirò a venirne a capo proverò a scrivere qualcosa di semplice per il blog, come approccio.

[xinyiman]

mentre degli esempi per mongo (ma anche per altro) li puoi trovare qui
https://github.com/synopse/mORMot2/blob/master/ex/README.md

grazie nomorelogic, in effetti stavo guardando proprio quel test. Ma ripeto cercavo un esempio molto più semplice, ovvero il mapping della classe al db, la creazione di un oggetto, la persistenza al db json e poi magari recuperarlo. Quel codice è troppo complesso per imparare ad usare il framework, poi è pieno di ifdef che lo rendono discretamente illeggibile. L'AI mi aiuta un pò ma, alla fine della fiera, dimostra di essere non troppo I . Proverò a scrivere sui loro forum ufficiali, come consigli.

Mi piacerebbe approfondire, per quanto offre credo sia una libreria davvero super completa. Anche le performance sembrano egregie.

Grazie, se riuscirò a venirne a capo proverò a scrivere qualcosa di semplice per il blog, come approccio.

Mi sono sempre ripromesso di darci un occhiata ma non l'ho mai fatto. Se ne vieni a capo, come dire Nomorelogic il contributo di una serie di articoli gioverebbe a molti.

[nomorelogic]

visto che si parla di mongodb vorrei condividere una mia personale visione della gestione dei dati

partiamo dal fatto che mongodb è un database nato per la persistenza di oggetti json
il vantaggio del json è che si tratta di una struttura dati senza schema
questo ha dei vantaggi importanti di dinamicità e porta ad avere una certa libertà nel disegno di un database
questi sono dei vantaggi che un RDBMS non può avere

per contro rende più complicato gestire le relazioni e fare determinate query complesse
essendo uno schema libero questo è evidente, so anche che mongodb ha anche il suo "linguaggio" per ovviare (parzialmente) a questo problema; la realtà è che molta della logica che è possibile incapsulare nel db RDBMS in stored procedure, function, view, plsql, ecc... probabilmente deve essere portata fuori dal db ed implementata nel linguaggio client (con tutto quello che comporta)

recentemente molti RDBMS (postgres, mysql, mssql, ecc...) hanno introdotto il campo dati di tipo json
non solo il tipo, ma hanno anche potenziato il DML per poter lavorare con questi campi

poniamo quindi di avere una tabella documenti dove abbiamo un campo chiamato full_json_data di tipo json
ad esempio mysql permette una sintassi del genere
(il simbolo del $ indica la root dei dati json nel campo)

Codice: [Seleziona]

select 
       id_doc
       , JSON_EXTRACT(full_json_data, "$.data_doc")       as "data_doc"
       , JSON_EXTRACT(full_json_data, "$.id_ordine")      as "id_ordine"
       , JSON_EXTRACT(full_json_data, "$.id_magazzino")   as "id_magazzino"
       , JSON_EXTRACT(full_json_data, "$.righe[0].id")    as "id_articolo_1"
       , JSON_EXTRACT(full_json_data, "$.righe[1].id")    as "id_articolo_2"
       , JSON_EXTRACT(full_json_data, "$.righe[2].id")    as "id_articolo_3"
       , JSON_EXTRACT(full_json_data, "$.righe[3].id")    as "id_articolo_4"
from documenti
where id_azienda = 'ABC' and JSON_EXTRACT(full_json_data, "$.id_cliente") =5
order by id 

ovviamente c'è anche il modo di trasformare automaticamente, con una funzione, il risultato di una SELECT in un oggetto JSON


secondo me questo approccio permette di mantenere l'uso delle potenzialità di un RDBMS e di affiancarlo alla dinamicità del json
basti pensare che la sintassi vista sopra permette di creare viste, funzioni, ecc... che accedono al json

purtroppo non tutti gli RDBMS hanno questa funzionalità
ma penso anche che mongodb, per ora, non riuscirà a mettere insieme i pregi dei 2 mondi

nomorelogic


Edit:
questo non vuole ovviamente dire di non usare mongodb
è una mia riflessione che viene dal mondo dove lavoro io: gestionali, ERP e simili
chiaramente non tutte le applicazioni sono di questo tipo
altre applicazioni non avranno bisogno dei pregi dei RDBMS
l'importante è prevederlo

[slapshot]

Ciao ! Dico la mia anche se solo da un punto di vista teorico. Forse il vantaggio maggiore di un db nosql è proprio la possibilità di mappare in modo diretto il Business Object Model sviluppato senza cercare meccanismi particolari per mappare gli oggetti ai db relazionali. Ovviamente sviluppare un'applicazione in questo modo richiede impegno e un cambio radicale, appoggiarsi all'MVC o ad altri pattern per astrarsi anche dalla gui. Implica non dover usare il rad ecc..

Per le performance non saprei, alcuni dicono che un db nosql sia molto veloce in alcuni casi, estendibile anche a più server. In altri casi, ovviamente, sarà più lento.

[DragoRosso]

Porto il mio punto di vista.
Non uso Json normalmente (in genere non sono un amante di ciò che abbraccia Java ...), e pochi giorni fà ho postato in un forum proprio sull'argomento Json dove qualche utente si lamentava che un suo wrapper Json non riconosceva un "campo" Json con un "1.0" perchè lo voleva o come "1" o come "1e0".

Lo documentazione ufficiale riporta:

JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange.

JSON offre invece solo la rappresentazione dei numeri che utilizzano gli esseri umani: una sequenza di cifre. Tutti i linguaggi di programmazione sanno come dare un senso alla sequenza di cifre anche se sono in disaccordo sulle rappresentazioni interne. Ciò è sufficiente per consentire lo scambio.

Per cui il valore doveva essere riconosciuto (nota: il tutto è nato perchè nell'ultima versione di Delphi viene aggiunto un ".0" ai numeri decimali anche se sono a valore intero) comunque sia con che senza ".0". E su ciò concordo.

Sulla citazione non tanto però ...

Questo solo come spunto per dire che un qualsiasi dato secondo me deve essere interpretato in maniera inequivocabile, e usare un database dove si inseriscono dati in modalità mista (tipo variant) mi lascia molto perplesso.
Ulteriormente perplesso mi lascia il fatto che il dato di per se potrebbe essere incompleto perchè mancante di una parte, senza che ci sia una definita e precisa schematica.

Posso capire che tale soluzione sia sicuramente più flessibile, alla maniera di Java, ma faccio davvero fatica a comprenderne i vantaggi nella generalità dei casi. Non nego che in qualche campo (magari più di qualche) possa essere una soluzione utile, ma provenendo da una cultura di programmazione sufficientemente rigorosa (pensate al Pascal) direi che non sarà un mio "must", anzi tuttaltro.

Ciao ciao

[slapshot]

Aggiorno qui !

Un pò di luce sul mongodb ad accesso diretto riesco a vederlo, non sto ancora testando ORM per accedervi. E' leggermente più lento ma, ovviamente, offre la possibilità di astrarre il BOM dal db sottostante. La libreria è sterminata, è un vero e proprio framework che va ben oltre il "semplice" ORM. Ci vorrà un bel pò di tempo, ma intanto ho iniziato a scavare. Non è roba da pubblicare, dovrò fare ancora molto per scrivere capendo ciò che c'è sotto. Le promesse sono davvero pazzesche. Vediamo come evolverà !