2013-09-04 7 views
5

Mam kwerendy próbki ze śliskiego jak poniżej:chcą wiedzieć lepszy sposób łączenia tabel z zręczny

val query = 
    (for { 
    (company,loc) <- Company leftJoin Location on (_.locId === _.id) 
    (_,typeof) <- Company leftJoin Types on (_.typeId === _.id) 
    } yield (company, loc, typeof)) 

jest lepszym sposobem na stwardnienie łączy?

Próbowałem sugestii w multiple joins with slick, ale w wyniku błędów.

+0

Co masz na myśli w lepszy sposób? Co jest z tym złego? –

+0

Widziałem wygenerowane zapytanie generujące wiele zapytań w tej samej tabeli Company dwa razy i łączących się raz z lokalizacją i raz z typem. Zwykle w sql dzieje się to w jednym zapytaniu wielokrotnych sprzężeń. Chcesz wiedzieć, czy coś jest z tym nie tak. – dsr301

Odpowiedz

4

ta działa poprawnie.

for { 
    ((company,geo),typeof) <- Company 
     leftJoin Location on (_.locId === _.id) 
     leftJoin Business_Levels on (_._1.typeId === _.id) 
} 
+0

To odpowiada na twoje pytanie, prawda? Proszę oznaczyć ją jako odpowiedź w tym przypadku :). Dzięki – cvogt

2

Można łańcuch sprzężenia normalnie:

for { 
    (company, location, type) <- Company 
     leftJoin Location on (_.locId === _.id) 
     leftJoin Types on (_._1.typeId === _.id) 
} yield (company, location, type) 

A tak przy okazji, jestem całkiem pewien, że słowo type to scala zastrzeżone słowo.

EDYCJA: Dodano _.1 na linii 3 po komentarzu dsr301.

+0

yep, type to keyword, post nie ma oryginalnych nazw z jakichś powodów. jakikolwiek sposób to zmienił. Daje mi błąd kompilacji z tym, o czym wspomniałeś powyżej. ")" oczekiwano, ale "." uznany. at (_.typeId === _.id) – dsr301

+0

Po zmianie pełnego zapytania na samotnego otrzymującego ten błąd "identyfikator_typu nie jest członkiem (model.firma.type, model.Lokalizacja.type)". Myślę, że drugie sprzężenie jest wykonywane na krotce wygenerowanej z pierwszego połączenia – dsr301

+0

Zmieniono moją odpowiedź. –