Waterline version: 0.13.5-0
Node version: 10.8.0
NPM version: 6.4.1
Operating system: Windows 10
Hi, I am developing a web application with sails js and waterline, I wanted to use 'cascade delete' functionality in waterline (in PostgreSQL client) and I realized that foreign keys not defined at database level and foreign key column is like other columns and there is no foreign key constraint on it.
This problem causes performance reduction and inability to use functionalities like cascade delete and update.
please add this feature in next releases, thanks.
馃尮
Alirezamohammadi
All 4 comments
@Alirezamohammadi Thanks for posting, we'll take a look as soon as possible.
For help with questions about Sails, click here. If you’re interested in hiring @sailsbot and her minions in Austin, click here.
sailsbot
on 10 Oct 2018
The use of foreign keys (and other constraints) is compatible with Waterline and SailsJS. It's just that this needs to be set up at the database level, and cannot be done using tables/auto-migrations.
streleck
on 11 Oct 2018
The use of foreign keys (and other constraints) is compatible with Waterline and SailsJS. It's just that this needs to be set up at the database level, and cannot be done using tables/auto-migrations.
Yes that's right, but I think if this constraints create automatically when ORM is building tables for the first time is better.
What do you think?
Alirezamohammadi
on 18 Oct 2018
I agree with you @Alirezamohammadi that constraints should be implemented at the database level for a better data coherence and an overall better speed. Waterline is an amazing tool but lack a deep bounding with the database IMHO. Moreover, it doesn't provide a production database migration tool from what I saw and I'm lacking that for my project as well.
I'm not saying it is the idea of the year but I decided to use Waterline as a read only tool and I create my database structure using db-migrate. It isn't ideal as I need to input my database structure twice but at the end of the day, I have a powerful querying tool (Waterline) and a reliable and migratable database structure that I will be plugging to a CI tool.
A database evolves by definition and I therefore don't think that creating the proper schema at the project startup would fly.
The best take for me would be to merge Waterline and db-migrate so the migration files would be created automatically like in the Doctrine ORM but that's a tough one to do!
Zaziffic
on 21 Nov 2018
Related issues
anissen
路
3Comments
G2Jose
路
4Comments
MelwinKfr
路
4Comments
randallmeeker
路
4Comments
svmn
路
4Comments
Most helpful comment
I agree with you @Alirezamohammadi that constraints should be implemented at the database level for a better data coherence and an overall better speed. Waterline is an amazing tool but lack a deep bounding with the database IMHO. Moreover, it doesn't provide a production database migration tool from what I saw and I'm lacking that for my project as well.
I'm not saying it is the idea of the year but I decided to use Waterline as a read only tool and I create my database structure using db-migrate. It isn't ideal as I need to input my database structure twice but at the end of the day, I have a powerful querying tool (Waterline) and a reliable and migratable database structure that I will be plugging to a CI tool.
A database evolves by definition and I therefore don't think that creating the proper schema at the project startup would fly.
The best take for me would be to merge Waterline and db-migrate so the migration files would be created automatically like in the Doctrine ORM but that's a tough one to do!