René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Relational expressions in foreign key definitions","articleBody":"Foreign keys may be more expressively defined using the same relational operators used in queries.  \r\n\r\nMultiple foreign keys made from the primary key, for example, may be viewed as the join:\r\n\r\n```\r\n-\u003e Scan\r\n-\u003e Method\r\n```\r\nis equivalent to \r\n```\r\n-\u003e Scan.proj() * Method.proj()\r\n```\r\nSince only primary keys are used in foreign key references, then the `.proj()` is redundant and we could use simply\r\n```\r\n-\u003e Scan * Method\r\n```\r\n\r\nA particular improvement would result for renamed foreign keys.  For example, in the current syntax, to reference to the `User` table as `experimenter, we use the syntax\r\n```\r\n(experimenter) -\u003e User\r\n```\r\nInstead, we could use the `proj` operator for renaming\r\n```\r\n-\u003e User.proj(user=\"experimenter\")\r\n```\r\n\r\nThis becomes particularly useful for more complex cases.  Users could actually test the expression before making it a foreign key.\r\n\r\nFor example, let's define a Synapse with references to presynaptic and postsynaptic Cells within a Scan. Currently, this would be declared as\r\n```\r\n# Synapse\r\n-\u003e Scan\r\n(presyn) -\u003e Cell(cell)\r\n(postsyn) -\u003e Cell(cell)\r\n```\r\nInstead it could be defined as \r\n```\r\n# Synapse\r\n-\u003e Scan * Cell.proj(presyn=\"cell\") * Cell.proj(postsyn=\"cell\")\r\n```\r\nFinally, foreign keys to unions (See #324) use the union operator in the foreign key, resulting in more intricate expressions as detailed in that issue.\r\n\r\nThis approach uses the same set of concepts as relational expressions and helps consolidate these ideas in the student's mind.\r\n\r\nAllowed operators are are join, proj, and union.  Since `aggr` and restriction have no way of affecting the primary key, they are not allowed.  Similarly, `dj.U` is not allowed because it is not referable. \r\n\r\nThe change is not backward compatible for renamed foreign keys if we fully commit to the `proj` syntax.  Since renamed foreign keys have not yet gained wide use with less experienced users, I think this is the right time to introduce the change.  We could keep both forms for a while and gradually deprecated the old renaming scheme. ","author":{"url":"https://github.com/dimitri-yatsenko","@type":"Person","name":"dimitri-yatsenko"},"datePublished":"2018-01-17T05:43:37.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/436/datajoint-python/issues/436"}