Replies: 1 comment
-
아 blocked 가 42가 MAX였었네요ㅋㅋㅋㅋㅋㅋㅋㅋ 근데 마지막에 말한 경우 QueryBuilder쓰는거 괜찮지 않아요? 뭐 사실 저의 경우야 컬럼도 2개 밖엔가 없어서 굳이굳이? 싶긴했지만 이건 사이즈도 좀 되고 하니까....... 지수님 말대로 수치화해서 볼 수 있으면 참 좋겠네요.... 나에게 시간만 많이 주고 코딩하도록 감시한다면 이런 것도 찾아볼텐데!!!!! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
앗 엔터칠 생각이 아니었는데.......
TypeORM은 뭘 하든 결과를 entity 에 담아줍니다. 그것이 ORM 이니까.. 하지만 이러면 짜증날 때가 정말 많습니다. 가령 #70 에서 @anso33 님이 고민하신 부분이라던지... 분명 blockedUserId 라는
number
만 필요한데 쓸데없이blockedUser
라는 객체에 싸서 오니까요..!해결책으로 raw query 가 있습니다. 말 그대로 커넥션을 열어서 진짜 query 를 날리는 것인데 그러면 결과를 저희가 어케저케 맘대로 가능합니다. 근데 생각해보면 이래도 파싱은 해야 합니다..SQL Injection 도 막아야 하고 transaction 처리가 필요하면 또 따로 해줘야 하고..........
뭔가 중간 방법이 있을까 싶으면서도 아직은 잘 모르겠네요.
제 생각에는 blocked user id 라던지 friend id 같이 많아봤자 call 당 42개인 정보 (한정됨) 는 그냥 TypeORM 이 주는 대로 받아서
map
으로 가공을 또 하는 것도 나쁘지 않다고 생각합니다.. 몇백만개가 아니라면 성능상 이상이 없을 것 같거든요!다른 분들 생각을 어떠신가요? 궁금합니다~! @anso33 @Kimhan-nah
또 의문이 생겼습니다.. 그렇다면 어차피 map 돌아야 할 거 select 를 주는 게 맞을까?
select 에는 얼마의 비용이 들까요?
Friendship entity 는 이렇게 생겼습니다.
만약 sender 관계로 User 와 Friendship 을 조인한다면 , 이렇게 생긴 데이터가 날아올 것입니다.
friendship: { id, sender객체, accpet, lastMessageTime}
여기서 제가 필요한 정보는 sender 객체이므로 이런 코드를 쓰겠죠?
받은데이터배열.map((friendship) => friendship.sender));
근데 sender 만 필요한데 굳이 select all 할 필요가 있을까요?
find()
메소드를 쓸 때select :{}
option 을 주면 select 하는 쿼리를 날려서 정제된 데이터가 옵니다.friendship: {sender 객체}
이걸로도 같은 동작이 가능합니다.아 .. 근데 후자로 하려면
QueryBuilder
를 사용해야 합니다.......... typeORM 이 제공하는Repository
에서는Relation
으로 조인을 하는데 이건 select 가 안되기 때문입니다... 그냥 맘대로 하도록 합시다.....................Beta Was this translation helpful? Give feedback.
All reactions