Allow defining a rel table with multiple src/dst node tables

[ray6080]

Real world applications can contain relationships with a large number of SRC/DST node table combinations.
Right now, we strictly force a rel table to be defined only with one src and one dst node table, which is best optimized. However, in terms of better user experience, we should gradually relax this restriction to support defining a rel table with multiple src/dst node tables.

[crtomirmajer]

This is currently indeed an awkward limitation when working with more generic relationships, such as eg. Likes, Owns, PartOf, that are usually connecting various node types. It would be great to have the ability to provide an expression that easily matches eg. "all things user likes", as (a:User)-[:Likes]-(b:Song:Playlist:User). Without the need to define individual UserLikesSong, UserLikesPlaylist, UserLikesUser REL TABLES, which complicates the given match example.

CREATE REL TABLE could probably be modified in a non-breaking way to support this behavior, by allowing multiple FROM {sources} TO {destinations}, {multiplicity} expressions, where both sources and targets are lists, and REL is created for all combinations:

CREATE REL TABLE Likes (
        FROM User TO Song, Playlist, User, ONE_MANY,
	FROM A, B TO C, D, ONE_ONE
);

This would make User->Song, User->Playlist, User->User, A->C, A->D, B->C, and B->D connections possible.

[ray6080]

Hi @crtomirmajer , thanks for the suggestion! Yeah, indeed the syntax you propose makes a lot sense to me. It is quite close to what we have discussed internally 😄

[crtomirmajer]

What's the priority of this issue? Any ETA?

[ray6080]

Hi @crtomirmajer , we hope to add the support of this feature before the end of Aug, so it will be available on our master branch by then. But the release of it will wait until an official release in the mid of Sep.

[andyfengHKU]

This should be available now with CREATE REL TABLE GROUP