Issue in setting foreign key

[MirnaV]

I was trying an app with one to many relation. I created the app using CompoundJS with MySQL backend.

describe('Author', function () {
property('name', String);
set('restPath', pathTo.authors);
});

describe('Book', function () {
property('title', String);
property('isbn', String);
property('authorId', Number,{foreignKey:true});
set('restPath', pathTo.books);
});

Book.hasMany(Author, {as: 'author', foreignKey: 'authorId'});
Author.belongsTo(Book, {as: 'books', foreignKey: 'authorId'});

While migrating the foreign key field is generated but the foreign key constrain is not being defined.

[dgsan]

Currently jugglingdb-mysql foreign keys do not utilize in-DB foreign key constraints as juggling currently doesn't differentiate between the various MySQL storage engines (MyISAM, InnoDB, etc.). Rather, as has been traditional in MySQL, particularly with users of MyISAM, columns are merely indexed.

The main advantage of using in-DB foreign key constraints with InnoDB and similar is the ability to control how referential integrity is dealt with on deletes/update/insert. However, this would be at the cost of having to program differing behaviors based on the table's storage engine at a fair number of places in the code. Likewise, it would also result in a potential need to make special cases for DBs that are made of tables with a mixture of storage engines.

If you feel that there's a significant benefit to having explicit materialized in DB foreign keys, it is (of course) possible to manually add them directly.

The minimum implementation of this feature is probably enabling the hasMany/belongsTo calls to detect the storage engine in use and then add/create the foreign key constraint if the engine detected supports and it does not already exist, or maybe to do so only when given an additional options (materializeConstraint: true?).

If you can write a decent implementation with unit tests, I wouldn't be opposed to adding it, but this also isn't something I'm likely to prioritize personally.