-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure the correct FK field name is used in link table rules #19
Conversation
Change-Type: patch
@pimterry, status checks have failed for this PR. Please make appropriate changes and recommit. |
Forgot to update the tests correspondingly - now fixed (though I question the value of a test suite that needs bug fixes that are near-identical to the real code...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took a bit of time to figure out how to resolve the relationship correctly in the lf-to-abstract-sql context (it's only been used in other contexts previously), but it turns out it's actually really simple, here's the code I used:
LinkTable :actualFactType =
RoleBindings(actualFactType):binds
LinkTableAlias(binds, actualFactType):tableAlias
GetTable(actualFactType):linkTable
{['SelectQuery', ['Select', []], ['From', [linkTable.name, tableAlias]]]}:query
{ _.each(binds, function(bind, i) {
var baseIdentifierName = actualFactType[i*2][1],
targetTable = $elf.GetTable(baseIdentifierName);
if(!targetTable.primitive) {
var relationshipMapping = $elf.relationships[linkTable.name][baseIdentifierName].$;
$elf.AddWhereClause(query,
['Equals',
['ReferencedField', tableAlias, relationshipMapping[0]],
['ReferencedField', bind.binding[1], relationshipMapping[1][1]]
]
);
}
})
}
-> ['Exists', query],
Basically a relationship mapping is [ $fromField, [ $toTable, $toField ] ]
(or just [ $fromField ]
if it's a primtiive attribute - which it won't be here). If you could check that out and see if it still works for you that'd be great, it passes the tests at least
This code assumes that the FK from a link table to another table has the same name as the target table. That's sometimes true, but not always - nowadays we include the verb in there. This breaks some parts of the billing model.
This code now searches the fields for a FK that connects to the correct table, which fixes this issue.
There's a further extension to this where we find the FK for the correct verb, since there could be multiple. I haven't looked at that because a) it doesn't block me and b) I can't see an easy way to connect the fields to the verbs without writing special logic to parse verb & field names, which seems pretty nasty. Any ideas?
Connects to #18
Change-Type: patch