Data/Schema scoping
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
Hướng nghiên cứu
Không có tệp hoặc bài kiểm thử nào được nêu tên. Hãy bắt đầu bằng việc xem xét schema và mô hình dữ liệu hiện có cùng với các điểm vào của WebAPI, sau đó xác định cách các tài nguyên toàn cục và tài nguyên có phạm vi theo portal hiện đang được biểu diễn. Công việc được xem là hoàn tất khi có một mô hình phạm vi đã được thống nhất, duy trì việc sử dụng toàn cục, xử lý các schema và dữ liệu dành riêng cho portal, đồng thời giải quyết các xung đột tên.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Currently, all schemas and the data they contain are global for the whole instance.
I believe the solution only makes sense if we can at least be able to scope it by portal. A PortalId field here would do it for the data but not for the schema. One site may want a Contact table that has 3 fields and no relations but the other site also want's a Contact table but with 10 fields and 3 relations. Those schemas would be incompatible.
For other uses cases, the instance owner may want to have a schema/data that is global for all portals and would hate this feature.
One solution to implement this without breaking the global option would be to add an optional _portalId to the table names.
So Contacts would be global for the instance, but Contacts_1 and Contacts_2 would be scoped per portal.
This leaves us with just the naming conflict between the global and portal specific ones... I am not sure what is the best way to solve this one but I think that since it's all WebAPI driven, the APIS could have a portalId in their request, if not provided they would serve the global one but if provided would serve the portal specific one.
- Ngôn ngữ chính
- C#
- Star
- 12
- Fork
- 5
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của DNNCommunity/Dnn.StructuredContent
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
DNNCommunity/Dnn.StructuredContent#70 · 1 bình luận ·
-
We need to not throw back details of general exceptions to the frontend.Có thể làm lại được @valadas đã nhận 1841 ngày trước và không có pull request nào đang mở. Đang mởenhancement
DNNCommunity/Dnn.StructuredContent#69 · 2 reaction · 1 người được giao ·
-
Use ToLowerInvariant() for Better Language SupportCó thể làm lại được @mitchelsellers đã nhận 1842 ngày trước và không có pull request nào đang mở. Đang mởenhancement
DNNCommunity/Dnn.StructuredContent#61 · 3 reaction · 1 người được giao ·
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
DNNCommunity/Dnn.StructuredContent#52 · 1 reaction ·
-
Persona Bar module needs a localization keyCó thể làm lại được @valadas đã nhận 1843 ngày trước và không có pull request nào đang mở. Đang mở
DNNCommunity/Dnn.StructuredContent#26 · 1 reaction · 1 người được giao ·
Tất cả issue của DNNCommunity/Dnn.StructuredContent
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
MicrosoftLearning/PL-400_Microsoft-Power-Platform-Developer#231 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
joinrpg/joinrpg-net#5313 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[12.x] FixIncorrectOwnerIdRelationships can delete legitimate library roots when UserView shares the same pathCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
Maintainer thường phản hồi trong vòng 1 ngày