Leftmost: You wouldn't be able to have relationship changes in entity revisions, no
2016-01-11 01116, 2016
LordSputnik
I really think this new way is the cleanest way of doing things, and it's also easier to migrate to than the current new schema plan
2016-01-11 01154, 2016
LordSputnik
Also, moving to the "relationships on entity data" plan would still be possible, if we don't like the "relationship sets versioned" plan
2016-01-11 01108, 2016
LordSputnik
opatel99: if you claim the display bug task and submit, I'll check your PRs/JIRA tickets in about 12 hours
2016-01-11 01123, 2016
Leftmost
The set-per-pair notion seems really unintuitive to me, and the idea of fetching an arbitrary number of those sets, unioning their contained relationships, and then fetching those relationships seems no less complex than the scheme we decided upon.
2016-01-11 01149, 2016
LordSputnik
stanislas: similar to ^, please keep claiming testing tasks, because it pokes me to check your commits
2016-01-11 01110, 2016
LordSputnik
Leftmost: but the integrity of the system is much more reliable
2016-01-11 01128, 2016
LordSputnik
Since you have an individual relationship row for each relationship
2016-01-11 01107, 2016
Leftmost
I'm not sure I follow why that's different from the current setup.
2016-01-11 01118, 2016
LordSputnik
Set-per-pair is the only way of doing things, because set-per-entity means that you can easily get out of sync between two entities
2016-01-11 01145, 2016
LordSputnik
Which is my problem with what we have in the current plan
2016-01-11 01113, 2016
LordSputnik
On a database level, there's nothing stopping me updating the relationship set for entity A, and not for entity B, and now A authored B, but B wasn't authored by A
2016-01-11 01158, 2016
LordSputnik
Whereas with a RelationshipSet per pair, it's guaranteed that the forward and reverse directions of the relationship will be equivalent
2016-01-11 01107, 2016
Leftmost
That makes sense as a concern, but I think the complexity in fetching is problematic. To fetch entity A's rels, you have to fetch all sets for which it's source, fetch all sets for which it's target, union all of those results and then fetch the relationships.
2016-01-11 01102, 2016
LordSputnik
SELECT * FROM bookbrainz.entity_link WHERE entity1=<bbid> OR entity2=<bbid> LEFT JOIN bookbrainz.relationship_revision ... LEFT JOIN bookbrainz.relationship
2016-01-11 01122, 2016
Leftmost
Part of the problem I have with having separate rel revisions and entity revisions is that it also makes it more complex to consider a given entity as a snapshot at a given revision.
2016-01-11 01118, 2016
Leftmost
When you start splitting up different things into different types of revisions, you lose the holistic view of a revision.
2016-01-11 01131, 2016
LordSputnik
OK, but really the versioning of data and relationships is separate - no matter what changes happen to the data, the relationships should still be valid, and vice versa.
2016-01-11 01124, 2016
LordSputnik
And we can make them appear unified on the front-end, if we want to
2016-01-11 01129, 2016
Leftmost
I don't think that follows. No matter what changes happen to an edition's release date, the identifier sets should still be valid, and vice versa.
2016-01-11 01149, 2016
Leftmost
My preference at this point is to see if we can't find a solution that addresses both concerns.
2016-01-11 01114, 2016
LordSputnik
If they were valid before, they'll be valid after the change
2016-01-11 01131, 2016
LordSputnik
The change to release date doesn't change the validity of identifiers
2016-01-11 01155, 2016
LordSputnik
But I think we should keep identifiers on the <entity>_data table, since those *do* belong to the data
2016-01-11 01103, 2016
LordSputnik
well, the identifier set id, anyway
2016-01-11 01142, 2016
Leftmost
I'm using that as an example of why your statement doesn't follow to me; I can use the same logic to say that we need to version release dates separately from identifiers, or any arbitrary piece of data on an entity should be versioned separately from any other arbitrary piece of data.
2016-01-11 01100, 2016
LordSputnik
The thing is, if I create a revision which adds a relationship to an entity, I don't think its parent should be the last revision to that entity's data
2016-01-11 01102, 2016
Leftmost
In the end, I just don't agree that relationships aren't part of an entity's data.
2016-01-11 01120, 2016
Leftmost
Why?
2016-01-11 01131, 2016
LordSputnik
Leftmost: but they aren't part of an entity's data. They're part of the data of two entities
2016-01-11 01104, 2016
Leftmost
That doesn't mean it's less part of the data of one of those entities. They're just unique in that they are part of the data of multiple entities.
2016-01-11 01139, 2016
LordSputnik
Which is why they're so tricky to version
2016-01-11 01131, 2016
Leftmost
It is, but I disagree that a relationship isn't part of an entity's data. I don't, however, disagree that the way we're representing them is suboptimal.
2016-01-11 01119, 2016
LordSputnik
Alright, what if we have a RelationshipSet object, with an ID, but scrap the "source" flag
2016-01-11 01154, 2016
LordSputnik
The RelationshipSet has entity_data1 and entity_data2 attributes
2016-01-11 01104, 2016
LordSputnik
So it's linked to the entity data of two entities
2016-01-11 01111, 2016
LordSputnik
Hmm
2016-01-11 01140, 2016
LordSputnik
But that still leaves the problem of the Revision affecting two <Entity>Revisions at a time
2016-01-11 01103, 2016
LordSputnik
Unless we perform two revisions to update the entity datas one at a time to use the new RelationshipSet
2016-01-11 01141, 2016
Leftmost
Yeah. I haven't thought this through fully, but I'm wondering if we can place a constraint that ensures that deleting a relationship from one set deletes it from the other. (As I said, not fully thought-through.)
2016-01-11 01117, 2016
opatel99
LordSputnik: Doing it now.
2016-01-11 01157, 2016
LordSputnik
Leftmost: the problem I have with Revision having many <Entity>Revisions is that it means that it has several parent revisions, which is also exactly how we represent merging
2016-01-11 01110, 2016
LordSputnik
And I don't want to complicate merging any further :P
2016-01-11 01133, 2016
Leftmost
I'm not sure I follow how that complicates merging.
2016-01-11 01139, 2016
LordSputnik
it probably complicates the display of merging, because the way to tell if a revision performs a merge is to count the number of parents at the moment
2016-01-11 01156, 2016
opatel99
LordSputnik: Marked as Complete
2016-01-11 01105, 2016
opatel99
Sorry. ^ Submitted for Review.
2016-01-11 01114, 2016
Leftmost
Anyhow, it'll take me some time to process. I'll see if I have anything by Usual Meeting Time tomorrow.
2016-01-11 01118, 2016
Leftmost
I'll think about that as well.
2016-01-11 01123, 2016
LordSputnik
opatel99: You're not a mentor yet haha ;)
2016-01-11 01131, 2016
LordSputnik
Leftmost: OK :)
2016-01-11 01137, 2016
LordSputnik
Let's try to solve this tomorrow
2016-01-11 01116, 2016
LordSputnik
I want to be done with writing the migration script so we can finally start finishing the models and direct-database
2016-01-11 01125, 2016
opatel99
I got to finish this Facebook API project in the meantime. For a technical mammoth, their docs can definitely be better.
2016-01-11 01146, 2016
Leftmost
Same. Sorry I haven't been much use recently.
2016-01-11 01147, 2016
LordSputnik
opatel99: documentation quality is inversely proportional to the size of the project ;)
2016-01-11 01127, 2016
LordSputnik
opatel99: hmm, or maybe not, maybe it's more of a parabola with "number of employees" as a variable too
