Quali caratteristiche orm.xml deve essere evitato per rimanere di database agnostico?

Question

Sono intraprendere un'avventura in APP e vogliono, in quanto possibile, rimanere di database agnostico. Quali caratteristiche orm.xml devo evitare di rimanere di database agnostico?

Per esempio, se io uso strategy="AUTO" in orm.xml come segue:

<id name="id">
    <generated-value strategy="AUTO" />
</id>

... allora MySQL lo mostra come una colonna AUTO_INCREMENT che può (io non sono ancora sicuro) causare problemi se avevo bisogno di distribuire a Oracle.

Answer 1

caratteristiche JPA

• È possibile utilizzare tutte le funzionalità JPA. Al peggio è necessario cambiare le annotazioni o orm.xml (ad esempio se si desidera utilizzare una speciale sequenza di Oracle), ma tutte le funzioni sono supportate in un modo o nell'altro, senza impattare il codice . Questo è ciò che è bello, con un ORM -. Si dispone di un extra-livello di astrazione

le parole chiave riservate

• Non utilizzare parola riservata dare un nome alle tabelle e le colonne

Tenere vicino al SQL-92 standard di

Il modo in cui le query vengono tradotti (soprattutto quelli nativi) è allentato. Questo è grande, in qualche caso, ma può portare ad alcuni problemi di volte:

• Non utilizzare AS nelle query native
• Non usare mai SELECT * nelle query native
• = utente per l'uguaglianza e non ==
• Utilizzare solo le SQL-92 funzioni standard

Answer 2

Non ho familiarità con JPA, ma in generale un ORM ragionevole dovrebbe essere di database agnostico (per le principali banche dati) per tutti i suoi mappature.

In particolare una strategia di incremento "AUTO" dovrebbe funzionare out of the box ..

Quando si passa il database, si ha a che fare con problemi di migrazione per i dati esistenti.

Answer 3

In generale, MySQL "AUTO_INCREMENT" dovrebbe essere usato quando si seleziona generazione di valore di "identità", e Sybase seriale e su DB2 ... ecc Alcuni RDBMS non hanno qualcosa di equivalente.

generazione di valore "AUTO" è per l'implementazione di scegliere ciò che è meglio per quel datastore. Sì, su MySQL possono scegliere AUTO_INCREMENT, e Sybase seriale e su Oracle SEQUENZA, ecc ecc, ma dal punto di vista del codice utente che uno (dovrebbe) funzionare su qualsiasi implementazione spec-compliant. Ovviamente non si può quindi passare implementazioni JPA e si aspettano di utilizzare lo stesso meccanismo esatto, dal momento che JPA impl # 1 può scegliere AUTO_INCREMENT su MySQL, e JPA impl # 2 può scegliere qualche meccanismo interno ecc ecc.