{"issue":{"state":"closed","created_at":"2011-11-20T11:32:02Z","updated_at":"2011-11-22T18:06:48Z","comments":4,"user":{"gravatar_id":"2a812bdd1b242988b293b218d02c881e","id":574167,"url":"https://api.github.com/users/timowest","login":"timowest","avatar_url":"https://secure.gravatar.com/avatar/2a812bdd1b242988b293b218d02c881e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"When join predicates are not given they should be added based on RelationalPath metadata.\r\n\r\ne.g.\r\n\r\ninstead of \r\n\r\nfrom(customer).innerJoin(order).on(order.customerId.eq(customer.id))\r\n\r\nfrom(customer).innerJoin(order) // join predicates are determined based on relational path metadata\r\n\r\nThis could be enabled via a SQLQuery constructor argument and would be disabled by default.","assignee":null,"id":2292103,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"number":51,"labels":[{"name":"idea","color":"02d7e1","url":"https://api.github.com/repos/mysema/querydsl/labels/idea"}],"title":"SQL : Add missing join predicates","html_url":"https://github.com/mysema/querydsl/issues/51","closed_at":"2011-11-22T18:06:48Z","url":"https://api.github.com/repos/mysema/querydsl/issues/51","milestone":null},"action":"created","comment":{"created_at":"2011-11-22T18:06:48Z","updated_at":"2011-11-22T18:06:48Z","user":{"gravatar_id":"2a812bdd1b242988b293b218d02c881e","id":574167,"url":"https://api.github.com/users/timowest","login":"timowest","avatar_url":"https://secure.gravatar.com/avatar/2a812bdd1b242988b293b218d02c881e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"> What about Q-type enhancement: from(customer.innerJoin(order)) ?\r\nLooks good, but I'd like to keep the join methods on the query level for maintenance simplicity and also to keep query and expression things separate.\r\n\r\nBut something like this could be used on the Scala side.\r\n\r\n>Anyway, what if there are multiple FKs between the tables?\r\nYes, missing and ambiguous FK:s would cause problems at runtime.\r\n\r\nMaybe improving the naming of foreign keys is a better approach. I will close this issue. \r\n\r\nYou are right that adding this kind of functionality at the Querydsl Core level goes against the principles of this framework.","id":2837856,"url":"https://api.github.com/repos/mysema/querydsl/issues/comments/2837856"}}