Hibernate: hbm2ddl.auto = pembaruan dalam produksi?


339

Apakah boleh menjalankan aplikasi Hibernate yang dikonfigurasikan hbm2ddl.auto=updateuntuk memperbarui skema basis data di lingkungan produksi?


6
Kita melakukannya. Tidak pernah punya masalah.
cretzel

4
Pertanyaan yang sangat bagus Saya hadapi sekarang. Jadi sekarang 2018 - setelah 10 tahun apa pendapat Anda? Apakah aman untuk menggunakan pembaruan Hibernate pada database produksi klien penting dengan skema kompleks?
Kirill Ch

Jawaban:


388

Tidak, ini tidak aman.

Meskipun upaya terbaik dari tim Hibernate, Anda tidak bisa mengandalkan pembaruan otomatis dalam produksi . Tulis tambalan Anda sendiri, ulas dengan DBA, ujilah, lalu terapkan secara manual.

Secara teoritis, jika pembaruan hbm2ddl bekerja dalam pengembangan, itu harus bekerja dalam produksi juga. Namun dalam kenyataannya, tidak selalu demikian.

Bahkan jika itu berhasil OK, itu mungkin kurang optimal. DBA dibayar sebanyak itu karena suatu alasan.


33
Mengapa itu tidak aman?
cretzel

74
Itu tidak aman karena tambalan yang diterapkan mungkin memiliki efek samping yang sulit diprediksi oleh hbm2ddl (seperti menonaktifkan pemicu yang dipasang untuk tabel yang sedang dimodifikasi). Untuk skema kompleks, cara teraman adalah manual. Otomatis dengan pengujian pasca-regresi adalah yang kedua. Semua IMHO.
Vladimir Dyuzhev

18
Memperbarui skema db juga harus ditangani oleh para profesional (dbas). Memulihkan dari perubahan db buruk sulit di terbaik. Vova tidak menyebutkannya - tetapi apa yang terjadi jika pembaruan hibernate memutuskan untuk menjatuhkan kolom dan menambahkannya kembali karena jenis atau ukurannya berubah. Dan katakanlah kolomnya adalah semua alamat email pengguna Anda? :-) bye, bye company ..... Anda ingin perubahan DDL dihasilkan secara otomatis - tetapi Anda benar-benar ingin perubahan diperiksa oleh manusia.
Pat

9
tidakkah Anda membuat cadangan basis data sebelum peningkatan?
Yakub

21
Namun, saat ini pembaruan skema Hibernate tidak menjatuhkan tabel atau kolom.
Brian Deterling

70

Kami melakukannya dalam produksi meskipun dengan aplikasi yang tidak kritis misi dan tanpa DBA dibayar tinggi pada staf. Ini hanya satu proses manual yang kurang dari kesalahan manusia - aplikasi dapat mendeteksi perbedaan dan melakukan hal yang benar, plus Anda mungkin telah mengujinya di berbagai pengembangan dan lingkungan pengujian.

Satu peringatan - di lingkungan yang berkerumun Anda mungkin ingin menghindarinya karena beberapa aplikasi dapat muncul pada saat yang sama dan mencoba untuk memodifikasi skema yang mungkin buruk. Atau masukkan mekanisme di mana hanya satu instance diizinkan untuk memperbarui skema.


2
Kami menggunakannya dalam Produksi juga, gunakan kasus serupa. Platform analitik yang tidak kritis terhadap misi. Kami telah mengerahkan 16K kali lebih dari 4 lingkungan (4Tahun) tanpa banyak cegukan dengan hibernate. Kami adalah tim kecil dan kebanyakan pemula SQL RDBS dan memiliki keyakinan yang lebih baik dalam skema penanganan Hibernate daripada yang kami lakukan sendiri. Saya ingin tahu berapa tingkat kesalahan untuk memiliki DBA pada staf yang mengelola perubahan skema dan migrasi? Apakah lebih baik dari 0 dalam ~ 16K menyebarkan?
user3263752

Apa yang akan Anda katakan tentang komentar ini dengan tepuk tangan? stackoverflow.com/questions/221379/…
Shiva kumar

52

Pembuat yang berhibernasi mencegahnya dalam lingkungan produksi di buku mereka "Java Persistence with Hibernate" :

PERINGATAN: Kami telah melihat pengguna Hibernasi mencoba menggunakan SchemaUpdate untuk memperbarui skema database produksi secara otomatis. Ini dapat dengan cepat berakhir dengan bencana dan tidak akan diizinkan oleh DBA Anda.


1
Apakah itu ditulis pada 2006?
user3263752

28

Lihat LiquiBase XML untuk menyimpan daftar perubahan pembaruan. Saya belum pernah menggunakannya sampai tahun ini, tetapi saya menemukan bahwa sangat mudah untuk belajar dan membuat kontrol revisi DB / migrasi / manajemen perubahan sangat mudah. Saya bekerja pada proyek Groovy / Grails, dan Grails menggunakan Hibernate di bawahnya untuk semua ORM-nya (disebut "GORM"). Kami menggunakan Liquibase untuk mengelola semua perubahan skema SQL, yang kami lakukan cukup sering karena aplikasi kami berkembang dengan fitur-fitur baru.

Pada dasarnya, Anda menyimpan file perubahan XML yang terus Anda tambahkan saat aplikasi Anda berkembang. File ini disimpan di git (atau apa pun yang Anda gunakan) dengan sisa proyek Anda. Ketika aplikasi Anda digunakan, Liquibase memeriksa tabel changelog di DB yang Anda sambungkan sehingga ia akan tahu apa yang telah diterapkan, lalu aplikasi itu secara cerdas hanya menerapkan perubahan apa pun yang belum diterapkan dari file. Ini berfungsi sangat bagus dalam praktiknya, dan jika Anda menggunakannya untuk semua perubahan skema Anda, maka Anda dapat 100% yakin bahwa kode yang Anda checkout dan gunakan akan selalu dapat terhubung ke skema database yang sepenuhnya kompatibel.

Yang luar biasa adalah bahwa saya dapat mengambil database mysql yang benar-benar kosong di laptop saya, menjalankan aplikasi, dan segera skema diatur untuk saya. Ini juga membuatnya mudah untuk menguji perubahan skema dengan menerapkannya pada dev-lokal atau pementasan db terlebih dahulu.

Cara termudah untuk memulai mungkin dengan mengambil DB yang ada dan kemudian menggunakan Liquibase untuk menghasilkan file baseline.xml awal. Kemudian di masa depan Anda bisa menambahkannya dan membiarkan liquibase mengambil alih mengelola perubahan skema.

http://www.liquibase.org/


Sempurna, hanya apa yang saya akan beralih ke. Saya merasakan hal terbaik, melangkah maju adalah menambahkan hbm2ddl.auto=updatesehingga pemetaan Kelas / DB Anda divalidasi dan Anda memiliki kendali penuh atas pembuatan DB melalui liquibase. Bagaimana menurut anda?
bholagabbar

Ups, validate
maksudku

liquibase lebih baik dalam mengelola skrip menggunakan "sertakan-impor" seperti dukungan dan dukungan Versi dan atribut "Jenis" untuk File yang membantu Anda untuk memiliki File SQL yang berbeda untuk lingkungan yang berbeda yang memiliki hubungan Orangtua Anak. Singkatnya, Go tradisional SQL Mgmt. dalam produksi. Untuk Pengembangan, kita membutuhkan Kecepatan Untuk Produksi, kita perlu Jaminan dan Stabilitas dan Cadangan.
Karan Kaw

26

Saya akan memilih tidak. Hibernate tampaknya tidak mengerti kapan tipe data untuk kolom telah berubah. Contoh (menggunakan 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

Mungkin ada contoh lain juga, seperti mendorong panjang kolom String lebih dari 255 dan melihatnya dikonversi ke teks, teks menengah, dll.

Memang, saya tidak berpikir ada cara untuk "mengkonversi tipe data" dengan tanpa membuat kolom baru, menyalin data dan membuang kolom lama. Tetapi begitu database Anda memiliki kolom yang tidak mencerminkan pemetaan Hibernate saat ini, Anda hidup dengan sangat berbahaya ...

Flyway adalah opsi yang baik untuk mengatasi masalah ini:

http://flywaydb.org


1
Saya baru saja mencoba bagian pertama dari contoh Anda - dalam kasus saya berubah @Column(length = 45)menjadi @Column(length = 255). Dapat memverifikasi bahwa Hibernate 4.3.6.Final benar memperbarui skema database menggunakan hbm2ddl.auto=update. (Satu hal yang perlu disebutkan adalah database saat ini tidak memiliki data di dalamnya - hanya strukturnya.)
Steve Chambers

Sangat mungkin mereka memperbaiki bug itu di suatu tempat ~ 6 tahun yang lalu. Namun jika Anda memang memiliki data dalam skema dan membuat perubahan yang mengakibatkan penurunan lebar kolom, Anda akan mengalami kesalahan atau pemotongan data yang tidak dikelola.
cliff.meyers

1
flywaydb membutuhkan skrip SQL yang dibuat secara manual, harus lebih baik daripada apa yang bisa dilakukan oleh program otomatis tetapi siapa yang bisa menulis skrip besar, maka itu masalah.
Rng Rikimaru

25

Hibernate harus meletakkan penafian tentang tidak menggunakan pembaruan otomatis di prod untuk melindungi diri mereka sendiri ketika orang-orang yang tidak tahu apa yang mereka lakukan menggunakannya dalam situasi di mana seharusnya tidak digunakan.

Memang situasi di mana itu tidak boleh digunakan sangat melebihi jumlah yang OK.

Saya telah menggunakannya selama bertahun-tahun di banyak proyek yang berbeda dan tidak pernah memiliki satu masalah pun. Itu bukan jawaban yang lemah, dan itu bukan pengkodean koboi. Itu fakta sejarah.

Seseorang yang mengatakan "tidak pernah melakukannya dalam produksi" sedang memikirkan serangkaian penyebaran produksi yang spesifik, yaitu yang ia kenal (perusahaannya, industrinya, dll).

Alam semesta "penyebaran produksi" sangat luas dan beragam.

Pengembang Hibernate yang berpengalaman tahu persis apa yang akan dihasilkan oleh DDL dari konfigurasi pemetaan yang diberikan. Selama Anda menguji dan memvalidasi bahwa apa yang Anda harapkan berakhir di DDL (dalam dev, qa, pementasan, dll), Anda baik-baik saja.

Saat Anda menambahkan banyak fitur, pembaruan skema otomatis dapat menghemat waktu nyata.

Daftar pembaruan otomatis hal-hal yang tidak akan ditangani tidak ada habisnya, tetapi beberapa contohnya adalah migrasi data, menambahkan kolom yang tidak dapat dibatalkan, perubahan nama kolom, dll, dll.

Anda juga perlu berhati-hati di lingkungan yang berkerumun.

Tetapi sekali lagi, jika Anda tahu semua hal ini, Anda tidak akan menanyakan pertanyaan ini. Hmm. . . OK, jika Anda mengajukan pertanyaan ini, Anda harus menunggu sampai Anda memiliki banyak pengalaman dengan pembaruan Hibernate dan skema otomatis sebelum Anda berpikir untuk menggunakannya di prod.


19

Seperti yang saya jelaskan di artikel ini , itu bukan ide yang baik untuk digunakan hbm2ddl.autodalam produksi.

Satu-satunya cara untuk mengelola skema basis data adalah dengan menggunakan skrip migrasi tambahan karena:

  • skrip akan berada di VCS di sepanjang basis kode Anda. Saat Anda checkout cabang, Anda membuat ulang seluruh skema dari awal.
  • skrip tambahan dapat diuji pada server QA sebelum diterapkan dalam produksi
  • tidak perlu intervensi manual karena skrip dapat dijalankan oleh Flyway , karena itu mengurangi kemungkinan kesalahan manusia terkait dengan menjalankan skrip secara manual.

Bahkan Panduan Pengguna Hibernate menyarankan Anda untuk tidak menggunakan hbm2ddlalat untuk lingkungan produksi.

masukkan deskripsi gambar di sini


Ini adalah jawaban yang sempurna dan setuju dengannya. Tapi saya benar-benar menemukan ide membuat skrip database pertama secara manual cumbersom (yaitu V1_0__initial_script.sql dalam kasus contoh di tautan). Apakah ada cara agar saya dapat membuat skrip dari db pengembangan yang ada yang dibuat Hibernate untuk saya dan simpan ke V1_0_intial_script.sql ??
HopeKing

1
Gunakan SchemaExportseperti yang ditunjukkan oleh test case ini .
Vlad Mihalcea

Terima kasih. Saya menemukan dump baris tunggal "mysqldump -u root -p --no-data dbname> schema.sql". Apakah ada kelemahan dalam menggunakan dump yang dihasilkan dari ini?
HopeKing

1
Tidak ada masalah menggunakan dump DB.
Vlad Mihalcea

8

Kami melakukannya dalam proyek yang berjalan dalam produksi selama berbulan-bulan sekarang dan tidak pernah memiliki masalah sejauh ini. Ingatlah 2 bahan yang dibutuhkan untuk resep ini:

  1. Desain model objek Anda dengan pendekatan kompatibilitas ke belakang, yaitu objek dan atribut yang sudah ketinggalan zaman alih-alih menghapus / mengubahnya. Ini berarti bahwa jika Anda perlu mengubah nama objek atau atribut, biarkan yang lama apa adanya, tambahkan yang baru dan tulis semacam skrip migrasi. Jika Anda perlu mengubah hubungan antara objek, jika Anda sudah dalam produksi, ini berarti bahwa desain Anda salah sejak awal, jadi coba pikirkan cara baru untuk mengekspresikan hubungan baru, tanpa memengaruhi data lama.

  2. Selalu cadangkan basis data sebelum penempatan.

Perasaan saya adalah - setelah membaca posting ini - bahwa 90% orang yang mengambil bagian dalam diskusi ini ngeri hanya dengan pemikiran untuk menggunakan otomatisasi seperti ini dalam lingkungan produksi. Beberapa melemparkan bola ke DBA. Luangkan waktu sejenak untuk mempertimbangkan bahwa tidak semua lingkungan produksi akan memberikan DBA dan tidak banyak tim pengembang mampu membelinya (setidaknya untuk proyek-proyek berukuran sedang). Jadi, jika kita berbicara tentang tim di mana setiap orang harus melakukan segalanya, bola ada pada mereka.

Dalam hal ini, mengapa tidak mencoba untuk mendapatkan yang terbaik dari kedua dunia? Alat-alat seperti ini ada di sini untuk membantu, yang - dengan desain dan rencana yang cermat - dapat membantu dalam banyak situasi. Dan percayalah, administrator mungkin awalnya sulit diyakinkan tetapi jika mereka tahu bahwa bola tidak ada di tangan mereka, mereka akan menyukainya.

Secara pribadi, saya tidak akan pernah kembali menulis skrip dengan tangan untuk memperluas segala jenis skema, tapi itu hanya pendapat saya. Dan setelah mulai mengadopsi database tanpa skema NoSQL baru-baru ini, saya dapat melihat bahwa lebih dari segera, semua operasi berbasis skema ini akan menjadi milik masa lalu, jadi Anda sebaiknya mulai mengubah perspektif Anda dan melihat ke depan.


4
Saya tidak setuju tentang komentar NoSQL. Sudah pasti sedang naik daun dan ada tempatnya, tetapi ada banyak aplikasi yang benar-benar bergantung pada kepatuhan ACID untuk integritas data dengan konkurensi dan transaksi yang tidak dapat disediakan oleh NoSQL.
jpswain

7

Saya tidak akan mengambil risiko karena Anda mungkin akan kehilangan data yang seharusnya disimpan. hbm2ddl.auto = pembaruan adalah murni cara mudah untuk memperbarui basis data dev Anda.


2
tidakkah Anda membuat cadangan basis data sebelum peningkatan?
Jacob

6
Ya tentu saja saya lakukan, tetapi banyak pekerjaan untuk memulihkan dari cadangan. Ini tidak sebanding dengan kerumitan mengembalikan cadangan ketika Anda juga dapat memperbarui database Anda secara teratur.
Jaap Coomans

6
  • Dalam kasus saya (Hibernate 3.5.2, Postgresql, Ubuntu), pengaturan hibernate.hbm2ddl.auto=updatehanya membuat tabel baru dan membuat kolom baru di tabel yang sudah ada.

  • Itu tidak menjatuhkan tabel, atau menjatuhkan kolom, atau mengubah kolom. Ini bisa disebut opsi yang aman, tetapi sesuatu seperti hibernate.hbm2ddl.auto=create_tables add_columnsakan lebih jelas.


6

Itu tidak aman, tidak disarankan, tetapi itu mungkin.

Saya memiliki pengalaman dalam aplikasi menggunakan opsi pembaruan otomatis dalam produksi.

Masalah utama dan risiko yang ditemukan dalam solusi ini adalah:

  • Menyebarkan dalam database yang salah . Jika Anda melakukan kesalahan untuk menjalankan server aplikasi dengan versi aplikasi yang lama (EAR / WAR / dll) dalam database yang salah ... Anda akan memiliki banyak kolom, tabel, kunci asing dan kesalahan baru. Masalah yang sama dapat terjadi dengan kesalahan sederhana dalam file sumber data, (salin / tempel file dan lupa mengubah database). Dalam resume, situasinya bisa menjadi bencana di database Anda.
  • Server aplikasi membutuhkan waktu terlalu lama untuk memulai . Ini terjadi karena Hibernate mencoba untuk menemukan semua tabel / kolom / etc yang dibuat setiap kali Anda memulai aplikasi. Dia perlu tahu apa (tabel, kolom, dll) yang perlu dibuat. Masalah ini hanya akan bertambah buruk ketika tabel database tumbuh.
  • Alat basis data hampir mustahil untuk digunakan . Untuk membuat skrip DDL atau DML database untuk dijalankan dengan versi baru, Anda perlu memikirkan apa yang akan dibuat oleh pembaruan otomatis setelah Anda memulai server aplikasi. Sebagai contoh, Jika Anda perlu mengisi kolom baru dengan beberapa data, Anda harus memulai server aplikasi, tunggu Hibernate, buat kolom baru dan jalankan skrip SQL setelah itu. Seperti yang dapat Anda lihat, alat migrasi basis data (seperti Flyway, Liquibase, dll) hampir tidak mungkin digunakan dengan pembaruan otomatis diaktifkan.
  • Perubahan basis data tidak terpusat . Dengan kemungkinan Hibernate membuat tabel dan yang lainnya, sulit untuk menonton perubahan pada database di setiap versi aplikasi, karena kebanyakan dari mereka dibuat secara otomatis.
  • Mendorong sampah pada basis data . Karena penggunaan pembaruan otomatis yang "mudah", ada kemungkinan tim Anda lalai untuk menjatuhkan kolom lama dan tabel lama, karena pembaruan otomatis hibernasi tidak dapat melakukannya.
  • Bencana yang akan segera terjadi . Risiko beberapa bencana yang akan terjadi dalam produksi (seperti beberapa orang disebutkan dalam jawaban lain). Bahkan dengan aplikasi yang berjalan dan diperbarui selama bertahun-tahun, saya pikir itu bukan pilihan yang aman. Saya tidak pernah merasa aman dengan opsi ini digunakan.

Jadi, saya tidak akan merekomendasikan untuk menggunakan pembaruan otomatis dalam produksi.

Jika Anda benar-benar ingin menggunakan pembaruan otomatis dalam produksi, saya sarankan:

  • Jaringan yang terpisah . Lingkungan pengujian Anda tidak dapat mengakses lingkungan homolog. Ini membantu mencegah penyebaran yang seharusnya di lingkungan Uji mengubah database Homologation.
  • Kelola pesanan skrip . Anda perlu mengatur skrip Anda untuk dijalankan sebelum penggunaan Anda (perubahan struktur tabel, drop table / kolom) dan skrip setelah penyebaran (isi informasi untuk kolom / tabel baru).

Dan, berbeda dari posting lain, saya tidak berpikir pembaruan otomatis diaktifkan itu terkait dengan DBA "dibayar sangat baik" (seperti yang disebutkan dalam posting lain). DBA memiliki hal-hal yang lebih penting untuk dilakukan daripada menulis pernyataan SQL untuk membuat / mengubah / menghapus tabel dan kolom. Tugas sehari-hari sederhana ini dapat dilakukan dan diotomatisasi oleh pengembang dan hanya diberikan kepada tim DBA untuk ditinjau, tidak perlu Hibernate dan DBA "dibayar sangat baik" untuk menulisnya.


4

Tidak, jangan pernah melakukannya. Hibernate tidak menangani migrasi data. Ya, itu akan membuat skema Anda terlihat dengan benar tetapi tidak memastikan bahwa data produksi yang berharga tidak hilang dalam proses.


4
  • Biasanya aplikasi perusahaan di organisasi besar dijalankan dengan hak istimewa yang dikurangi.

  • Nama pengguna basis data mungkin tidak memiliki DDL hak istimewa untuk menambahkan kolom yang hbm2ddl.auto=updatemembutuhkan.


ini adalah masalah yang sering saya temui. Kami mencoba menggunakan hibernasi untuk pembuatan DB awal tetapi seringkali tidak memungkinkan untuk melakukannya.
Dan

5
Ini bukan "masalah", ini adalah Hal yang Benar.
Vladimir Dyuzhev

2

Saya setuju dengan Vladimir. Administrator di perusahaan saya pasti tidak akan menghargainya jika saya menyarankan kursus semacam itu.

Lebih lanjut, membuat skrip SQL sebagai ganti Hibernate yang mempercayai secara membabi buta memberi Anda kesempatan untuk menghapus bidang yang tidak lagi digunakan. Hibernate tidak melakukan itu.

Dan saya menemukan membandingkan skema produksi dengan skema baru memberi Anda wawasan yang lebih baik untuk apa Anda berubah dalam model data. Anda tahu, tentu saja, karena Anda berhasil, tetapi sekarang Anda melihat semua perubahan dalam sekali jalan. Bahkan yang membuatmu seperti "Apa-apaan ini ?!"

Ada alat yang dapat membuat skema delta untuk Anda, jadi itu bahkan bukan kerja keras. Dan kemudian Anda tahu persis apa yang akan terjadi.


"Ada alat yang dapat membuat skema delta untuk Anda": Bisakah Anda menunjukkan beberapa alat seperti itu?
Daniel Cassidy

Saya pikir apexsql.com/sql_tools_diff.asp melakukan ini, dan mungkin lebih banyak aplikasi. Saya biasanya melakukannya dengan tangan dengan membuang skema dan diffing (menggunakan diff).
extraneon

2

Skema aplikasi dapat berkembang dalam waktu; jika Anda memiliki beberapa instalasi, yang mungkin pada versi yang berbeda, Anda harus memiliki beberapa cara untuk memastikan bahwa aplikasi Anda, semacam alat atau skrip mampu memigrasikan skema dan data dari satu versi secara bertahap ke versi berikutnya.

Memiliki semua kegigihan Anda dalam pemetaan Hibernate (atau anotasi) adalah cara yang sangat baik untuk menjaga evolusi skema terkendali.

Anda harus mempertimbangkan bahwa evolusi skema memiliki beberapa aspek untuk dipertimbangkan:

  1. evolusi skema basis data dalam menambahkan lebih banyak kolom dan tabel

  2. menjatuhkan kolom, tabel, dan relasi lama

  3. mengisi kolom baru dengan default

Alat Hibernate penting khususnya dalam kasus (seperti dalam pengalaman saya) Anda memiliki versi yang berbeda dari aplikasi yang sama pada berbagai jenis database.

Poin 3 sangat sensitif jika Anda menggunakan Hibernate, seperti jika Anda memperkenalkan properti bernilai boolean baru atau numerik, jika Hibernate akan menemukan nilai nol di kolom tersebut, jika akan memunculkan pengecualian.

Jadi apa yang akan saya lakukan adalah: lakukan memang menggunakan alat Hibernate kapasitas pembaruan skema, tetapi Anda harus menambahkan di sampingnya beberapa data dan panggilan balik pemeliharaan skema, seperti untuk mengisi default, menjatuhkan kolom tidak lagi digunakan, dan sejenisnya. Dengan cara ini Anda mendapatkan keuntungan (skrip pembaruan skema basis data independen dan menghindari pengkodean duplikat dari pembaruan, dalam ketekunan dan dalam skrip) tetapi Anda juga mencakup semua aspek operasi.

Jadi misalnya jika pembaruan versi hanya terdiri dari menambahkan properti bernilai varchar (maka kolom), yang mungkin default ke nol, dengan pembaruan otomatis Anda akan selesai. Di mana lebih banyak kompleksitas diperlukan, lebih banyak pekerjaan akan diperlukan.

Ini mengasumsikan bahwa aplikasi ketika diperbarui mampu memperbarui skema (dapat dilakukan), yang juga berarti harus memiliki hak pengguna untuk melakukannya pada skema. Jika kebijakan pelanggan mencegah hal ini (kemungkinan kasus Kadal Otak), Anda harus menyediakan skrip khusus basis data.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.