HEIBERNATE: HBM2DDL.AUTO = Update in productie?

Is het goed om hibernate-applicaties uit te voeren die zijn geconfigureerd met hbm2ddl.auto=updateom het database-schema in een productieomgeving bij te werken?

1, Autoriteit 100%

Nee, het is onveilig.

Ondanks de beste inspanningen van het Hibernate-team, kunt u eenvoudigweg niet vertrouwen op automatische updates in productie . Schrijf je eigen patches, bekijk ze met DBA, test ze, pas ze handmatig aan.

Theoretisch, als HBM2DDL-update in ontwikkeling gewerkt, zou het ook in de productie moeten werken. Maar in werkelijkheid is het niet altijd het geval.

Zelfs als het goed werkte, kan het sub-optimaal zijn. DBA’s worden om een ​​reden betaald.

2, Autoriteit 17%

Wij doen het in de productie, zij het met een toepassing die geen missie van kritisch is en zonder betaalde DBA’s op het personeel. Het is slechts een minder handmatig proces dat onderhevig is aan menselijke fout – de applicatie kan het verschil detecteren en het juiste ding doen, plus je vermoedelijk het in verschillende ontwikkelings- en testomgevingen hebt getest.

One Beanthing – In een geclusterde omgeving wilt u het misschien vermijden omdat meerdere apps tegelijkertijd kunnen komen en proberen het schema te wijzigen dat slecht kan zijn. Of in een bepaald mechanisme plaatsen waar slechts één instantie het schema mag bijwerken.

3, Autoriteit 14%

Hibernate Creators Discourage doen in een productieomgeving in hun boek “Java Persistentie met Hibernate “:

WAARSCHUWING: We hebben Hibernate-gebruikers gezien die SchemaUpdate proberen te gebruiken om het schema van een productiedatabase automatisch bij te werken. Dit kan snel eindigen op ramp en zal niet worden toegestaan ​​door uw DBA.

4, Autoriteit 7%

HEIBERNATE moet de disclaimer plaatsen over het niet gebruiken van automatische updates in prod om zichzelf te bedekken wanneer mensen die niet weten wat ze doen het gebruiken in situaties waar het niet mag worden gebruikt.

Toegegeven de situaties waarin het niet in de eerste plaats zou moeten worden gebruikt, waar het OK is.

Ik heb het al jaren op veel verschillende projecten gebruikt en heb nooit een probleem gehad. Dat is geen kreupel antwoord, en het is geen cowboycodering. Het is een historisch feit.

Een persoon die zegt: “Nooit doen in productie” denkt aan een specifieke reeks productie-implementaties, namelijk degenen die hij bekend is (zijn bedrijf, zijn industrie, enz.).

Het universum van “productie-implementaties” is enorm en gevarieerd.

Een ervaren Hibernate-ontwikkelaar weet precies wat DDL gaat opleveren bij een bepaalde mappingconfiguratie. Zolang je test en valideert dat wat je verwacht in de DDL terechtkomt (in dev, qa, staging, enz.), gaat het goed.

Als u veel functies toevoegt, kunnen automatische schema-updates u in realtime besparen.

De lijst met dingen die automatische updates niet kunnen verwerken, is eindeloos, maar enkele voorbeelden zijn gegevensmigratie, het toevoegen van niet-nullable kolommen, kolomnaamwijzigingen, enzovoort, enzovoort.

Ook in geclusterde omgevingen moet je voorzichtig zijn.

Maar nogmaals, als je al deze dingen wist, zou je deze vraag niet stellen. Hm. . . Oké, als je deze vraag stelt, moet je wachten tot je veel ervaring hebt met Hibernate en automatische schema-updates voordat je erover nadenkt om het in prod te gebruiken.

Antwoord 5, autoriteit 7%

Het is geen goed idee om hbm2ddl.autoin productie te gebruiken.

De enige manier om het databaseschema te beheren is door incrementele migratiescripts te gebruiken, omdat:

• de scripts zullen samen met uw codebase in VCS staan. Wanneer je een branch uitcheckt, creëer je het hele schema opnieuw.
• de incrementele scripts kunnen worden getest op een QA-server voordat ze in productie worden toegepast
• het is niet nodig om handmatig in te grijpen omdat de scripts kunnen worden uitgevoerd door Flyway, waardoor de kans op menselijke fout bij het handmatig uitvoeren van scripts.

Zelfs de Gebruikershandleiding Slaapstandraad u aan de tool hbm2ddlvoor productieomgevingen niet te gebruiken.

Antwoord 6, autoriteit 7%

Ik zou nee stemmen. Hibernate lijkt niet te begrijpen wanneer gegevenstypen voor kolommen zijn gewijzigd. Voorbeelden (met MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)
@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Er zijn waarschijnlijk ook andere voorbeelden, zoals het verhogen van de lengte van een String-kolom tot meer dan 255 en het zien converteren naar tekst, mediumtekst, enz.

Toegegeven, ik denk niet dat er echt een manier is om “datatypes te converteren” zonder een nieuwe kolom te maken, de gegevens te kopiëren en de oude kolom weg te blazen. Maar zodra uw database kolommen heeft die niet overeenkomen met de huidige Hibernate-toewijzing, leeft u zeer gevaarlijk…

Flyway is een goede optie om dit probleem aan te pakken:

http://flywaydb.org

Antwoord 7, autoriteit 2%

Ik zou het risico niet nemen, omdat je uiteindelijk gegevens zou kunnen verliezen die bewaard hadden moeten blijven. hbm2ddl.auto=update is puur een gemakkelijke manier om uw ontwikkelaarsdatabase up-to-date te houden.

Antwoord 8, autoriteit 2%

We doen het in een project dat al maanden in productie is en tot nu toe nooit een probleem gehad. Houd rekening met de 2 ingrediënten die nodig zijn voor dit recept:

1. Ontwerp uw objectmodel met een achterwaartse compatibiliteitsbenadering, dat wil zeggen afkeurenobjecten en attributen in plaats van ze te verwijderen/wijzigen. Dit betekent dat als u de naam van een object of attribuut moet wijzigen, de oude ongewijzigd laat, de nieuwe toevoegt en een soort migratiescript schrijft. Als je een associatie tussen objecten moet wijzigen, als je al in productie bent, betekent dit dat je ontwerp in de eerste plaats verkeerd was, dus probeer een nieuwe manier te bedenken om de nieuwe relatie tot uitdrukking te brengen, zonder oude gegevens te beïnvloeden.

2. Altijd back-upvan de database voorafgaand aan implementatie.

Mijn gevoel is – na het lezen van dit bericht – dat 90% van de mensen die aan deze discussie deelnemen, geschokt is door de gedachte om dergelijke automatiseringen in een productieomgeving te gebruiken. Sommigen gooien de balnaar de DBA. Neem echter even de tijd om te bedenken dat niet alle productieomgevingen een DBA zullen bieden en dat niet veel ontwikkelteams zich er een kunnen veroorloven (tenminste voor middelgrote projecten). Dus als we het hebben over teams waar iedereen alles moet doen, ligt de bal bij hen.

Waarom probeer je in dit geval niet gewoon het beste van twee werelden te hebben? Tools zoals deze zijn hier om een ​​helpende hand te bieden, die – met een zorgvuldig ontwerp en plan – in veel situaties kan helpen. En geloof me, beheerders zijn in eerste instantie misschien moeilijk te overtuigen, maar als ze weten dat de bal niet aan hun handen ligt, zullen ze het geweldig vinden.

Persoonlijk zou ik nooit meer handmatig scripts schrijven voor het uitbreiden van welk type schema dan ook, maar dat is slechts mijn mening. En nadat ik onlangs begonnen ben met het adopteren van NoSQL-schemaloze databases, kan ik zien dat al deze op schema’s gebaseerde bewerkingen meer dan binnenkort tot het verleden zullen behoren, dus je kunt maar beter je perspectief veranderen en vooruit kijken.

Antwoord 9

• In mijn geval (Hibernate 3.5.2, Postgresql, Ubuntu), zorgde het instellen van hibernate.hbm2ddl.auto=updatealleen voor nieuwe tabellen en nieuwe kolommen in reeds bestaande tabellen.

• Het heeft geen tabellen verwijderd, geen kolommen verwijderd of kolommen gewijzigd. Het kan een veilige optie worden genoemd, maar iets als hibernate.hbm2ddl.auto=create_tables add_columnszou duidelijker zijn.

10

Nee, doe het nooit. HEIBERNATE verlaagt geen gegevensmigratie. Ja, het zal uw schema correct laten uitzien, maar het zorgt ervoor dat waardevolle productiegegevens niet verloren gaan in het proces.

11

Ik ben het eens met Vladimir. De beheerders in mijn bedrijf zouden het zeker niet waarderen als ik zelfs een dergelijke cursus heb voorgesteld.

Verder biedt het maken van een SQL-script in plaats van blindelings vertrouwend Hibernate u de mogelijkheid om velden te verwijderen die niet langer in gebruik zijn. Slaapstand doet dat niet.

En ik vind het vergelijken van het productiesschema met het nieuwe schema geeft u nog beter inzicht in wat u in het gegevensmodel veranderde. Weet je, natuurlijk, omdat je het hebt gehaald, maar nu zie je alle veranderingen in één keer. Zelfs degenen die je laten gaan “wat de HECK?!”.

Er zijn hulpmiddelen die een schema-delta voor u kunnen maken, dus het is zelfs niet hard werken. En dan weet je precies wat er gaat gebeuren.