07 - TypeORM many to many relations with custom properties - Typescript

Buy me a coffee if this is useful 😀
www.buymeacoff...
repo:
github.com/Row...
DOCS:
many to many:
typeorm.io/#/m...
~~~~~~~~~~~~~~~~~~~~~~
follow me
twitter: / rowadthesecond
LinkedIn: / mohammed-al-rowad
Github: github.com/Moh...

[@leblanc2572]

Thank you so much bro, you helped me a lot!

[@gerardocardenas8805]

Bueno video, excelente, ahora, como puedo tener dos llaves compuestas, por ejemplo: post y categoria like (PK), no como (FK)?

[@yageroi]

if i create this sort of table to replace an existing auto generated junction table by using the same name, do i have to do extra work to keep from blowing away data in the current junction table? would that be a good approach or is it better to create an additional table in the way described here to support custom additional columns?

[@Rowadz]

that's an interesting question, I would say it's always better to create an entity in TypeORM to represent junction tables because you most likely will need to add new columns there at some point, plus you can use some TypeORM features like listeners and subscribers on this relationship which might be powerful in some cases
for your case, I think the only way to ""move"" the data there, is to create a new entity that will represent the junction table with the same name plus add the new columns there, and I believe TypeORM is smart enough to understand what you are doing, so it will just add new columns to the already existing table and keep your data.
notes::
1 - do this scenario on a copy of your tables/database, might be annoying to set up BUT it will make sure you don't delete important data!
2 - try to use migrations to update tables.
3 - do not pass `true` to synchronize in the create connection function, passing true will drop the whole database and build it again
I hope this was useful

[@NapoleonBonaparte81]

thanks man. keep going , really helped me lot

[@Rowadz]

I'm glad that I helped :)

[@hussain5755]

can you please make a video showing HOW TO ADD DATA TO THESE many-to-many TABLES ?? Thanks a lot in advance

[@Rowadz]

I did a video about this
ruclips.net/video/uPX8xtC2NDw/видео.html
here is the full play list
ruclips.net/p/PLM0LBHjz37LVtZY-DG0OrZzZkkRtWGR6B

[@feelwang]

Just playing with TypeORM coming from Sequelize. It sucks. After modeling, Sequelize offers "magic functions" to gear you up with all the saving and updating. The whole business of many to many relationship CRUD jobs are reduced to modeling. Yet, TypeORM. OMG. Correct me and I thank you deeply. They cannot even perform a simple full-load query with the condition on the relation entity. Query build can bring you as far as just your directly related table and I have to sub query to the get the relation entity data which just failed the whole point of modeling effort. I am still in shock. I guess I can utilize their seemingly explicit query builder to do all the leftJoin, innerJoin query building stuff. but hey...that's what modeling is supposed be taking care.

[@Rowadz]

if I understood the issue
I think to get nested relations on find query ( SQL multiple joins )
you do this
userRepository.find({
join: {
alias: "user",
leftJoinAndSelect: {
profile: "user.profile",
photo: "user.photos",
video: "user.videos"
}
}
});
you can put a dot for each relation to join with them
another example
userRepository.find({ relations: ["profile", "photos", "videos", "videos.video_attributes"] });
and to add a where condition on the relations you might use the query builder
typeorm.io/#/select-query-builder
const user = await createQueryBuilder("user")
.leftJoinAndSelect("user.photos", "photo")
.where("user.name = :name", { name: "Timber" })
.andWhere("photo.isRemoved = :isRemoved", { isRemoved: false })
.getOne();
or (left join with where on a relation)
const user = await createQueryBuilder("user")
.leftJoinAndSelect("user.photos", "photo")
.where("user.name = :name", { name: "Timber" })
.andWhere("photo.isRemoved = :isRemoved", { isRemoved: false })
.getOne();

[@Rowadz]

I hope this answers the question or points you out to something useful

[@feelwang]

@@Rowadz thanks. But still, my point, I don't want to think about this. Modelling should make it easy to not go through this hey wires. Also updating, their cascade is not applicable to relations either. And their soft-delete as well, not applicable to relation either. Soft-delete is more shocking than N:N modeling as I just learned.