- Verschickt
- 8. November 2026 um 08:35 UTC
- Autor
- Kamo
- Commit
- d100d86
Die Arbeitsauftragsnummern waren COUNT(jobs)+1, also konnten sich zwei gleichzeitig erhobene Jobs einen teilen, Und Jobs, die aus einer bezahlten Bestellung (ServiceFulfillmentPolicy) erhoben wurden, erhielten überhaupt keine Nummer. ServiceJobNumbers speichert jetzt WO-00001… unter einer PESSIMISTIC_WRITE Sperre auf dem Server der Organisation commerce_document_counter Zeile (DocumentType.SERVICE_JOB, Serie Jahr 0 — ein laufendes Jahr) Serie), die einmal von der höchsten WO- Nummer der Organisation ausgewählt werden createJob ist @RetryOnDbConflict für Yugabytes 40001 auf einem beanspruchten Pfad Zähler. ux_service_job_org_number (org_id, job_number) ist der Backstop, angewendet durch hand NONCONCURRENTLY nachdem die Null-Zahlen nachgefüllt wurden. Ein Auftrag wechselt nicht mehr durch eine Statusänderung zu Invoiced: Invoiced bedeutet eine Rechnung Es existiert, und nur das Erstellen eines (InvoicingService) setzt einen Job dort. CommerceInvoicePayment (commerce_invoice_payments, von Hand angewendet) zeichnet jedes Zahlung gegen eine CommerceInvoice, also die Spalten AMOUNT_PAID / PAID / PARTIALLY_PAID CommerceInvoiceRepository erhält einen row-locked read und einen row-locked write ServiceJobRepository erhält claimForInvoicing.