2012-11-27 48 views
6

Tôi có ứng dụng Rails và ứng dụng Sinatra, dùng chung cơ sở dữ liệu. Ứng dụng Sinatra sử dụng ActiveRecord.Cách quản lý di chuyển khi nhiều ứng dụng dùng chung cơ sở dữ liệu trong Ruby?

Tôi có thể chạy di chuyển từ bên trong mỗi ứng dụng, như thể chúng nằm trong cùng một ứng dụng không? Điều này có gây ra bất kỳ vấn đề nào không?

File schema.rb trong ứng dụng Rails theo dõi sự di cư hiện qua

ActiveRecord::Schema.define(:version => 20121108154656) do 

nhưng, làm thế nào để ứng dụng Sinatra biết phiên bản hiện tại cơ sở dữ liệu?

Đường ray 3.2.2, Ruby 1.9.3.

Trả lời

0

tôi quyết định đặt tất cả di cư trong ứng dụng Rails vì:

  1. Kể từ khi chỉ có một cơ sở dữ liệu
  2. Rails quản lý di cư

này đã làm việc tốt.

Điều này đơn giản hóa hệ thống vì tất cả các di chuyển được lưu trữ ở một nơi. Và, ứng dụng Sinatra không cần phải biết về chúng.

+0

có gì sai với câu trả lời của tôi? Bạn đã chọn một trong các tùy chọn tùy chọn thứ hai mà tôi đã đề cập ... – Schmurfy

+0

Chỉ có một cơ sở dữ liệu. –

3

Nếu bạn kết nối cả hai ứng dụng cơ sở dữ liệu mà bạn nên có thể chạy di cư vào nó nhưng tôi đề nghị bạn nên sử dụng tùy chọn khác kể từ khi bạn gần như chắc chắn sẽ đánh một bức tường cùng một lúc này hay cách khác:

  • chia cơ sở dữ liệu thành hai nếu có thể với mỗi ứng dụng chịu trách nhiệm về cơ sở dữ liệu/di chuyển của chính nó.

  • có một ứng dụng được coi là "bậc thầy" cơ sở dữ liệu và sử dụng cơ sở dữ liệu khác cho dữ liệu cụ thể cho các ứng dụng thứ hai nhưng làm cho nó kết nối với cả hai cơ sở dữ liệu (mỗi ứng dụng vẫn chỉ áp dụng di cư đến một cơ sở dữ liệu)

Nếu bạn cần chia sẻ dữ liệu giữa nhiều ứng dụng, một tùy chọn khác là triển khai dịch vụ REST trong một và sử dụng dịch vụ này trên một dịch vụ khác, bạn có thể xem đá quý nho để biết cách làm đơn giản.

Chỉnh sửa: Tôi nhận ra rằng tôi quên nói về việc di chuyển activerecord, không còn bất kỳ "phiên bản" nào của lược đồ nữa, điều mà activerecord thực hiện là đọc tất cả tên tệp di chuyển của bạn, trích xuất số nhận dạng của chúng (phần bắt đầu) và kiểm tra xem chúng đã được áp dụng sao cho lý thuyết bạn có thể chạy di chuyển từ hai ứng dụng trên cùng một cơ sở dữ liệu với điều kiện chúng không can thiệp. Nhưng nếu cả hai di chuyển hành động trên cùng một bảng, bạn gần như chắc chắn sẽ gặp rắc rối lớn tại một thời điểm.

+0

+1 để đề xuất api REST. – harald

+0

Tôi không nghĩ một trong hai giải pháp đó có hiệu quả vì cả hai đều cần chia sẻ cùng một dữ liệu, và tôi nghĩ đơn giản hơn để chạy một cơ sở dữ liệu ... Nhưng có lẽ tôi có thể đặt tất cả các di chuyển trong ứng dụng Rails ... –

+0

Tôi đã thêm giải thích về cách hoạt động của chuyển động activerecord, cách cả hai ứng dụng độc lập? Nếu bạn có thể phân phối/cài đặt/triển khai cả hai cùng một lúc thì bạn có thể quyết định rằng một trong số họ chịu trách nhiệm cho việc di chuyển và thậm chí có cả hai trong cùng một git/svn/.... – Schmurfy

1

Tôi không đồng ý với Schmurfy, ngay cả khi các tùy chọn được trình bày của ông là hợp lệ, một chút quá mức cần thiết để chia sẻ dữ liệu qua REST (được cấp, khá dễ thực hiện với ruby ​​/ ray).

Nếu trường hợp của bạn đơn giản, bạn chỉ có thể sử dụng một cơ sở dữ liệu từ cả hai ứng dụng và vì bạn sử dụng AR trong cả hai ứng dụng này, bạn không gặp vấn đề gì với phiên bản, AR sẽ xử lý vấn đề đó.

Ngoài ra tôi không biết những gì sẽ xảy ra nếu bạn chạy db: di chuyển từ cả hai ứng dụng simultaniously nếu bạn sử dụng một DBMS kém như mysql mà không cho phép DDL trong một giao dịch, chắc chắn không có gì tốt ..

Ngoài ra nó sẽ làm phiền tôi để xem ứng dụng nào cần cột nào và không có di chuyển ở một nơi. Bạn có thể sử dụng kho lưu trữ được chia sẻ để quản lý việc di chuyển từ cả hai ứng dụng.

+0

Tôi sẽ không chạy sự di cư đồng thời ... –

+0

Tôi chỉ muốn chỉ ra một cạm bẫy không đáng kể rõ ràng. – Andreas

1

Đường dẫn di chuyển lưu trữ phiên bản cơ sở dữ liệu hiện tại trong schema_migrations bảng trong cơ sở dữ liệu. Vì vậy, cả hai ứng dụng của bạn sẽ có thể kiểm tra phiên bản hiện tại.

Số phiên bản là dấu thời gian, vì vậy sẽ không có vấn đề gì với các giá trị trùng lặp, vì hầu như không thể tạo hai lần di chuyển với cùng một mili giây. Vì vậy, bạn nên ổn ở đây.

Vấn đề duy nhất tôi thấy là khi bạn khôi phục di chuyển trong một ứng dụng, nó sẽ đặt db thành phiên bản đã biết trước đó và tôi không chắc liệu nó sẽ chọn phiên bản trước đó từ db hay không từ ứng dụng khác) hoặc số từ tệp di chuyển trước đó. Bạn có thể muốn kiểm tra kịch bản đó để đảm bảo.

4

Cột phiên bản trong bảng schema_migrations tương đương với dấu thời gian ở mặt trước của tệp di chuyển ruby ​​ví dụ: 20130322151805_create_customers.rb Vì vậy, nếu hai ứng dụng nhiều hơn đang đóng góp vào bảng cuộn bảng schema_migrations sẽ không thể thực hiện được nếu đường ray có thể không tìm thấy phương thức down() (vì nó sẽ không tìm thấy tệp di chuyển có trong ứng dụng khác, ví dụ: db/migrate/...)

Tôi có tình huống hiện tại chính xác và tôi đã chọn có ứng dụng chủ ActiveRecord quản lý di chuyển và chuyển đổi dữ liệu khi cơ sở dữ liệu của chúng tôi phát triển. Hãy nhớ rằng một phần của thỏa thuận là để giữ cho các mô hình cập nhật là tốt. Điều này đã tốn thời gian vì vậy chúng tôi đang cân nhắc việc tách DB ra khỏi lĩnh vực kinh doanh và cung cấp API (JSON) để truy vấn dữ liệu hỗ trợ cho một ứng dụng khác. Bằng cách này, mỗi ứng dụng quản lý miền đó và chịu trách nhiệm cho việc hiển thị dữ liệu qua API.

liên quan.

Các vấn đề liên quan