2016-10-31 17 views
13

Cách tốt nhất để thay đổi mô hình dữ liệu Firebase trong khi bạn có nhiều phiên bản ứng dụng iOS trong sản xuất là gì?Thay đổi mô hình dữ liệu Firebase (trong khi nhiều phiên bản ứng dụng đang trong quá trình sản xuất)

Vì không có lớp 'máy chủ ứng dụng' ở giữa bất kỳ thay đổi nào trong mô hình cơ sở dữ liệu có thể phá vỡ các phiên bản cũ hơn của ứng dụng.

Performance liên quan Ví dụ về vấn đề:

Trong phiên bản 1.0 tôi đã ngây thơ giữ tất cả mọi thứ liên quan đến một bài dưới '/ posts /'. Bây giờ trong phiên bản 2.0, tôi muốn đưa ra đề xuất của Firebase và thêm điểm cuối '/ user-post' để nhanh chóng liệt kê tất cả các bài đăng của một người dùng cụ thể.

Những người sử dụng phiên bản 1.0 của ứng dụng iOS không ghi bất kỳ dữ liệu nào vào '/ user-posts' vì điểm cuối đó không tồn tại. Do đó, những người sử dụng phiên bản 2.0 sẽ không thấy bất kỳ bài đăng nào được tạo bởi những người đang sử dụng phiên bản ứng dụng cũ.

Về lý thuyết, tôi có thể tạo một máy chủ ở đâu đó để nghe những thay đổi về '/ post /' và thêm chúng vào '/ user-posts'. Điều đó có vẻ khó duy trì theo thời gian mặc dù nếu bạn có nhiều phiên bản ứng dụng khác nhau.

New Ví dụ Tính năng của vấn đề:

phép nói rằng trong phiên bản 1.0 của ứng dụng di động của bạn, bạn viết bài đăng trên blog mới để '/ bài viết /'. Hiện tại trong phiên bản 2.0 của ứng dụng, bạn giới thiệu tính năng Nhóm và tất cả các bài đăng cần phải có trong '/ team/team-id/posts'.

Những người chưa nâng cấp lên phiên bản 2.0 sẽ vẫn ghi vào '/ posts'. Những bài đăng đó sẽ không hiển thị với những người đang sử dụng phiên bản 2.0 đang đọc từ '/ team/team-id/posts'.

Tôi nhận ra rằng bạn có thể giữ cả hai điểm cuối cùng một lúc (và chỉ mục/bài đăng dựa trên ID nhóm) nhưng theo thời gian, điều này có vẻ khó duy trì.

các giải pháp truyền thống:

Nếu tôi đang sử dụng một cái gì đó giống như Django hoặc Express Tôi muốn làm một sự chuyển đổi cơ sở dữ liệu và sau đó cập nhật các thiết bị đầu cuối phía máy chủ để tạo blogposts.

Điều đó sẽ thay đổi cơ sở dữ liệu từ khách hàng. Tôi có thể về mặt lý thuyết thêm một tầng ứng dụng máy chủ để kiến ​​trúc của tôi với Firebase, nhưng điều đó không có vẻ như nó được đề nghị: https://firebase.googleblog.com/2013/03/where-does-firebase-fit-in-your-app.html

+1

Mặc dù tôi không thể nhận xét về cách di chuyển hoặc xử lý các thay đổi đối với ứng dụng hiện tại của bạn. Trong tương lai sẽ áp dụng các hằng số hợp lý và Cấu hình Từ xa Firebase có thể là một cách để giảm thiểu một số thay đổi cấu trúc dữ liệu. Ngoài ra, hãy sử dụng một số cơ chế để khuyến khích người dùng chuyển sang phiên bản mới nếu điều đó khả thi. Có lẽ bằng cách tạo các tính năng mới có sẵn ... –

Trả lời

3

tôi sẽ đề nghị bạn sử dụng Firebase Remote Config để hiển thị một cảnh báo qua UIAlertController hoặc màn hình khác nhau nếu có bản cập nhật có sẵn. Bạn có thể buộc người dùng cập nhật lên phiên bản hiện tại và sau này bạn không gặp vấn đề gì vì không thể tạo bài đăng có mã cũ.

Để trả lời câu hỏi của bạn: tôi sẽ phát triển một ứng dụng khác nhau, thêm nó vào dự án căn cứ hỏa lực cùng và sau đó cho phép ứng dụng này chuyển đổi tất cả dữ liệu cũ sang mô hình dữ liệu mới. Vì vậy, bạn sẽ làm điều này một lần sau khi phát hành phiên bản mới và dữ liệu người dùng cũ được chuyển đổi sang mô hình dữ liệu mới và mọi thứ hoạt động suôn sẻ. Bạn cũng có thể có một tài sản như databaseVersion cho mọi đối tượng.

Để ngăn chặn các sự cố trong tương lai, bạn có thể có một thuộc tính chung có tên là app-version trong Firebase Realtime Database của mình. Trước mỗi bài đăng, ứng dụng sẽ kiểm tra xem có phiên bản mới hơn hay không. Nếu không phải người dùng có thể thêm bài đăng nhưng nếu có phiên bản mới hơn, bạn có thể hiển thị thông báo/cảnh báo qua UIAlertController

+0

Cảm ơn đề xuất. Tôi đã xem xét buộc nâng cấp, nhưng điều đó có vẻ giống như một UX nghèo. Tôi đã kết thúc thực hiện tất cả các lần đọc trực tiếp từ FB, nhưng proxy ghi thông qua một máy chủ. Khi có thay đổi lược đồ, máy chủ sẽ ghi hai lần cả bài đăng lên vị trí cũ và vị trí mới. –

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