2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_maniphest.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_maniphest.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_repository.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_repository.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_differential.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_differential.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_file.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_file.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_user.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_user.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_project.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_project.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_metamta.edge (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
src VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
type VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dst VARCHAR(64) NOT NULL COLLATE utf8_bin,
|
|
|
|
|
dateCreated INT UNSIGNED NOT NULL,
|
|
|
|
|
seq INT UNSIGNED NOT NULL,
|
|
|
|
|
dataID INT UNSIGNED,
|
|
|
|
|
PRIMARY KEY (src, type, dst),
|
|
|
|
|
KEY (src, type, dateCreated, seq)
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|
|
|
|
|
|
2012-04-30 07:53:53 -07:00
|
|
|
CREATE TABLE {$NAMESPACE}_metamta.edgedata (
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-04 15:30:21 -07:00
|
|
|
id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
|
|
|
|
|
data LONGTEXT NOT NULL COLLATE utf8_bin
|
|
|
|
|
) ENGINE=InnoDB, COLLATE utf8_general_ci;
|