Hibernate annotation für PostgreSQL serial geben

Gefahr: Ihre Frage impliziert, dass Sie machen können ein design Fehler - Sie versuchen, eine Datenbank-Sequenz für ein "business" - Wert, der dem Benutzer präsentiert werden, in diesem Fall Rechnung zahlen.

Nicht eine Sequenz verwenden, wenn Sie brauchen, um etwas mehr als ein test der Wert für die Gleichstellung. Es hat keine Ordnung. Es hat keinen "Abstand" von einem anderen Wert. Es ist nur gleich, oder nicht gleich.

Rollback:
Sequenzen sind in der Regel nicht geeignet ist für solche verwendet werden, da änderungen an Sequenzen sind nicht Rollback mit der Transaktion ROLLBACK. Finden Sie die Fußzeilen auf Funktionen-Sequenz und CREATE SEQUENCE.

Rollbacks sind zu erwarten und normal. Sie treten aufgrund von:

• deadlocks verursacht durch widersprüchliche update-Auftrag oder sonstige sperren zwischen zwei Transaktionen;
• optimistic locking-rollbacks im Ruhezustand;
• transient-client-Fehler;
• server-Wartung durch die DBA;
• Serialisierung Konflikte in SERIALIZABLE oder snapshot-isolation-Transaktionen

... und mehr.

Ihre Anwendung haben "Löcher" in der Rechnung Nummerierung, wo diese rollbacks auftreten. Zusätzlich, dort ist keine Bestellung garantieren, so ist es durchaus möglich, dass eine Transaktion mit einem späteren Sequenz-Nummer zu Begehen, früher (manchmal viel früher), als man mit einer späteren Nummer.

Chunking:

Es ist auch normal für einige Anwendungen, einschließlich Ruhezustand, schnappen Sie mehr als einen Wert von einer Sequenz zu einer Zeit, und Sie aus der hand zu Transaktionen intern. Das ist zulässig, weil Sie nicht erwarten sollen, Sequenz-generierte Werte zu haben, eine sinnvolle Reihenfolge, oder werden die in irgendeiner Weise vergleichbar außer für die Gleichstellung. Für Rechnung Nummerierung, die Sie wollen bestellen zu, so dass Sie nicht an alle freuen, wenn Hibernate packt Werte 5900-5999 und beginnt mit übergabe Sie aus 5999 zählen unten oder abwechselnd-dann nach unten, so dass Sie Ihre Rechnung zahlen gehen: n, n+1, n+49, n+2, n+48, ... n+50, n+99, n+51, n+98, [n+52 verloren rollback], n+97, .... Ja, die high-dann low-Zuweisung existiert in Hibernate.

Es hilft nicht, dass, es sei denn, Sie definieren einzelne @SequenceGenerators in Ihren Zuordnungen, Hibernate teilen mag eine einzelne Sequenz für jeder generierte ID, zu. Hässlich.

Korrekte Verwendung:

Einer Sequenz ist nur angemessen, wenn Sie nur erfordern die Nummerierung eindeutig sein. Wenn Sie auch brauchen, es zu sein, die monotone und Ordnungszahl, sollten Sie sich Gedanken über die Verwendung eines gewöhnlichen Tisch mit einem Zähler-Feld über UPDATE ... RETURNING oder SELECT ... FOR UPDATE ("pessimistisches locking" in den Ruhezustand) oder via Hibernate optimistische sperren. Auf diese Weise können Sie garantieren lückenlose Schritten, ohne Löcher oder out-of-order-Einträge.

, Was zu tun ist, anstatt:

Erstellen Sie eine Tabelle nur für einen Zähler. Eine einzelne Zeile in es, und aktualisieren Sie es wie Sie es Lesen. Werde es sperren, verhindern, dass andere Transaktionen bekommen eine ID, bis deins verpflichtet.

Weil es zwingt alle Ihre Transaktionen zu betreiben, Seriell, versuchen Sie, um Transaktionen zu generieren, Rechnung IDs kurz und vermeiden Sie dabei mehr arbeiten, als Sie müssen.

CREATE TABLE invoice_number (
    last_invoice_number integer primary key
);

-- PostgreSQL specific hack you can use to make
-- really sure only one row ever exists
CREATE UNIQUE INDEX there_can_be_only_one 
ON invoice_number( (1) );

-- Start the sequence so the first returned value is 1
INSERT INTO invoice_number(last_invoice_number) VALUES (0);

-- To get a number; PostgreSQL specific but cleaner.
-- Use as a native query from Hibernate.
UPDATE invoice_number
SET last_invoice_number = last_invoice_number + 1
RETURNING last_invoice_number;

Alternativ können Sie:

• Definieren Sie eine entity für invoice_number, fügen Sie ein @Version Spalte, und lassen Sie das optimistische sperren kümmern, Konflikte;
• Definieren Sie eine entity für invoice_number und explizite pessimistische sperren in Hibernate zu tun, ein select ... for update dann ein update.

Alle diese Optionen werden Ihre Transaktionen zu serialisieren - entweder durch ein Rollback Konflikte mit der @Version, oder eine Blockierung (Verriegelung), bis der lock-Halter verpflichtet. so oder so, gapless-Sequenzen wirklich langsam, dass Bereich der Sie Ihre Anwendung, so verwenden Sie nur lückenlose Sequenzen, wenn Sie zu haben.

@GenerationType.TABLE: Es ist verlockend, zu verwenden @GenerationType.TABLE mit einem @TableGenerator(initialValue=1, ...). Leider, während GenerationType.TABELLE können Sie angeben, eine Zuordnung Größe via @TableGenerator, es nicht bieten keine Garantien bezüglich der Bestellung oder der rollback-Verhalten. Finden Sie die JPA-2.0-Spezifikation, Abschnitt 11.1.46, und 11.1.17. Insbesondere "Diese Spezifikation definiert jedoch nicht das genaue Verhalten dieser Strategien. und Fußnote 102 "Portable Anwendungen, sollten Sie nicht verwenden die GeneratedValue-annotation auf andere persistente Felder oder Eigenschaften [als @Id Primärschlüssel]". So ist es unsicher ist, verwenden Sie @GenerationType.TABLE für die Nummerierung, die Sie benötigen, um gapless oder Nummerierung, die nicht auf eine Primärschlüssel-Eigenschaft, es sei denn, dein JPA-provider macht mehr Garantien als der standard.

Wenn Sie fest sind, mit einer Folge:

Dem Plakat fest, dass Sie vorhandene apps mit der DB, die eine Sequenz verwenden, die bereits, so dass Sie ' re mit es stecken.

In der JPA-standard garantiert nicht, dass Sie verwenden können, erzeugt Spalten bis auf @Id, können Sie (a) ignorieren Sie das und gehen Sie vor, so lange, wie Sie Ihre Anbieter können, oder (b) machen Sie den Einsatz mit einem Standard-Wert und neu aus der Datenbank gelesen. Letzteres ist sicherer:

    @Column(name = "inv_seq", insertable=false, updatable=false)
    public Integer getInvoiceSeq() {
        return invoiceSeq;
    }

Weil insertable=false die Anbieter nicht versuchen, geben Sie einen Wert für die Spalte. Sie können nun legen Sie einen geeigneten DEFAULT in der Datenbank, wie nextval('some_sequence') und es werden geehrt. Haben Sie vielleicht eine re-Lesen Sie die Entität aus der Datenbank mit EntityManager.refresh() nach anhaltenden es - ich bin nicht sicher, ob das Persistenz-provider machen das für Sie, und ich habe nicht geprüft, spec oder geschrieben, ein demo-Programm.

Der einzige Nachteil ist, dass es scheint, die Spalte kann nicht gemacht werden, @ NotNull oder nullable=false, weil die Anbieter nicht begreifen, dass die Datenbank einen Standardwert für die Spalte. Kann es immer noch NOT NULL in der Datenbank.

Wenn Sie Glück haben anderen apps, wird auch die standard-Ansatz, der entweder das weglassen der Spalte "Sequenz" aus der INSERT's column list oder explizite Angabe der keyword - DEFAULT als der Wert, anstelle von aufrufen nextval. Es wird nicht schwer sein zu finden, dass durch die Aktivierung log_statement = 'all' im postgresql.conf und Suche in den logs. Wenn Sie das tun, dann können Sie tatsächlich schalten Sie alles, um lückenlose wenn Sie sich entscheiden, Sie brauchen, um durch den Austausch Ihrer DEFAULT mit einem BEFORE INSERT ... FOR EACH ROW - trigger-Funktion, die Sätze NEW.invoice_number von der Zähler-Tabelle.

Je nach situation, kann dies nicht funktionieren. Es gibt einen bug eröffnet gegen Hibernate, Dokumente, die für dieses Verhalten.

http://opensource.atlassian.com/projects/hibernate/browse/HHH-4159

Wenn Sie offen sind mit einer mapping-Datei, anstelle von Anmerkungen, ich habe wieder das Problem (NULL in der SERIELLEN Spalten, die nicht Teil des Primärschlüssels). Mit der "generated" - Attribut des property-Elements bewirkt, dass Hibernate re-read der Reihe nach einer insert -, pick-up die generierte Spalte Wert:

<class name="Ticket" table="ticket_t">
    <id name="id" column="ticket_id">
        <generator class="identity"/>
    </id>
    <property name="customerName" column="customer_name"/>
    <property name="sequence" column="sequence" generated="always"/>
</class>