Comments
1 comment
-
Generally the way this (should) work right now is to list items in the following order:
(1) JOIN conditions (at the moment we only support these based on foreign keys, but as I said in the release notes this is going to change and we'll figure out conditions based on name and type matching as well).
(2) Columns from all tables and views used in the query.
(3) All other columns (I think you're right that these all need to disappear though).
(4) Everything else (this needs to be here in case you want to do something a bit random like call a function, however the JOIN conditions will always be at the top so this shouldn't be a hindrance).
Hope that goes some way to addressing the issues you have. At the moment the JOIN support isn't as sophisticated as it could be, but we will be sorting it out. The main thing we wanted for this release was proper foreign key based support, including compound keys.
I suspect we'll probably have to add some configuration options to deal with JOINs so that your candidate list doesn't get too polluted with spurious conditions.
Thanks,
Add comment
Please sign in to leave a comment.
tableA
join tableB
on <-- the list pops up again
This list should only contain columns from tableA and or tableB. And it should prefer a foreign key that the table shares, a column they have in common (like if joining two views), and possibly if two columns in the different tables share a root (like accountId and masterAccountId) then a list of the tables values.
If you specify one column and then go to the list, the same name matching should be preferred, but then columns of the same datatype. If the types don't match, you could include cast() on the second one to make them match, perhaps?
A big niceity would be to have the capability to add user defined relationship info. I have a solution that implements a copy of a database using only views. So I could spec out possible joins. This would also be true for relationships that require triggers and cannot use proper DRI.