You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modeling-wise, I guess that instead of the user defining a join table, they'd define a join column which must be a (queryable) collection. Each side of the navigation would need to do this in order for the navigation to be bi-directional. No skip navigations would be involved.
Here's how this would work query-wise:
DROPTABLE IF EXISTS Blogs;
DROPTABLE IF EXISTS Posts;
CREATETABLEBlogs (Id INT IDENTITY PRIMARY KEY, PostIds NVARCHAR(MAX));
CREATETABLEPosts (Id INT IDENTITY PRIMARY KEY, Name NVARCHAR(MAX));
INSERT INTO Posts (Name) VALUES ('Post1'), ('Post2');
INSERT INTO Blogs (PostIds) VALUES ('[1, 2]');
SELECT*FROM Blogs AS b
CROSS APPLY OpenJson(b.PostIds) WITH (PostId int'$') AS pids
INNER JOIN Posts AS p ONp.Id= PostId;
I think it would still have to be implemented using skip navigations, as that's the only way of having an FK on each side, we just need to allow the FKs to be defined on different types and to use collection properties.
Similar to #23523 for Cosmos.
The text was updated successfully, but these errors were encountered: