Masalah ORM yang tidak menghalangi


9

Saya mengajukan pertanyaan pada SO, dan menemukan bahwa tidak ada ORM non-pemblokiran untuk kerangka web favorit saya. Maksud saya non-blocking adalah ORM dengan dukungan panggilan balik untuk pengambilan asinkron. ORM akan diberikan panggilan balik atau semacamnya untuk dieksekusi ketika data telah diterima.

Saya ingin membuatnya, tetapi saya memiliki beberapa pertanyaan yang menghalangi saya untuk memulai pengembangan:

  • Masalah apa yang mungkin dihadapi saat mengembangkan ORM?
  • Apakah mendukung pengambilan non-blocking secara dramatis meningkatkan kompleksitas ORM?
  • Mengapa ada beberapa ORM yang tidak menghalangi?

Pembaruan: Sepertinya saya harus meningkatkan pertanyaan saya. Kami memiliki solusi yang memungkinkan kami menerima data dengan cara yang tidak menghalangi, dan saya percaya bahwa sebagian besar perusahaan yang menggunakan solusi tersebut menggunakan SQL mentah. Kami ingin membuat solusi yang lebih umum yang dapat digunakan kembali dalam proyek mendatang. Kesulitan apa yang mungkin kita hadapi?

Pembaruan 2: Bahasa yang disukai adalah python, tapi saya tertarik pada prinsip. Pertanyaan ini sebenarnya untuk saya, karena saya akan melihat platform yang sudah memiliki ORM non-blocking.


2
Apa itu "ORM Non-blocking?" Bagaimana Anda bisa menampilkan data sebelum Anda menerimanya?
Robert Harvey

6
@RobertHarvey: pengambilan asinkron terdengar cukup bagus sebenarnya. ORM akan diberikan panggilan balik atau semacamnya untuk "mengaktifkan" ketika data telah diterima. Kalau tidak, ORM Anda perlu dibagi dalam utas terpisah untuk menjamin respons UI.
Marjan Venema

@MarjanVenema, ya, saya ingin ORM dengan dukungan panggilan balik.
Nikolay Fominyh

1
Jadi mengapa tidak hanya menggunakan panggilan balik asinkron dengan ORM sinkron favorit Anda? stackoverflow.com/q/1239035
Robert Harvey

@RobertHarvey, karena ORM sinkron memblokir server asinkron.
Nikolay Fominyh

Jawaban:


2

Masalah apa yang mungkin dihadapi saat mengembangkan ORM?

Anda harus mengatasi daftar masalah yang diperlukan untuk menjembatani Ketidaksesuaian Object Relational Impedance , serta berurusan dengan kekhasan SQL yang disediakan oleh masing-masing vendor RDBMS. Semakin maju persyaratan Anda, semakin buruk masalah Anda di departemen ini: misalnya, SQL yang Anda hasilkan untuk menerapkan hasil paging akan berbeda secara dramatis antara Oracle, SQL Server, dan mysql. Untungnya, ini tidak berbeda antara implementasi ORM blocking dan non-blocking, jadi jika ada ORM open-source untuk Python, Anda akan dapat meminjam banyak darinya untuk mengatasi hampir semua masalah ini.

Apakah mendukung pengambilan non-blocking secara dramatis meningkatkan kompleksitas ORM?

Masalah terbesar yang akan Anda hadapi adalah bahwa pustaka koneksi untuk mengakses RDBMS itu sendiri akan diblokir. Ini adalah perbedaan lain yang harus Anda atasi. Mengelola utas yang tidak terlihat oleh pengguna Anda akan menjadi tantangan tambahan bagi Anda. Selain itu, memuat dependensi pada permintaan akan menjadi tantangan, karena operasi dianggap sinkron oleh pengguna kerangka kerja Anda: setelah semua, mereka biasanya tidak mengharapkan pemberitahuan kapan OK untuk mengakses properti koleksi dari objek mereka.

Mengapa ada beberapa ORM yang tidak menghalangi?

Saya hanya bisa berspekulasi pada poin terakhir ini, tapi saya pikir itu ada hubungannya dengan permintaan rendah untuk kerangka kerja seperti itu: karena Anda dapat mensimulasikan sebagian ORM non-pemblokiran dengan menambahkan level lain dari threading ke kode aplikasi Anda sesuai kebutuhan, dan menjaga pemblokiran reguler baik di tempat lain, mengembangkan kerangka kerja khusus untuk itu akan tampak suboptimal.


Tidak yakin, apakah jawaban atas pertanyaan ini bisa lebih baik. Terima kasih.
Nikolay Fominyh

6

Anda tidak mengatakan bahasa yang Anda gunakan, jadi saya akan merekomendasikan Node.js, dan ORM untuk itu: Node ORM , semua yang ada di simpul adalah async, ini tidak berbeda.


Pertanyaan diperbarui.
Nikolay Fominyh
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.