Remove bias towards Sequelize about sails

[gavri]

sequelize does have a done() promise which accepts a cb(error, result) -style callback.

[mikermcneil]

Excellent point-- I'll take a look at that! (Wish I would have looked at that close before) I actually rather like the way Sequelize handles things.

Some of the most common feedback I've had from people getting started is the initial hurdle of the mySQL dependency and a lack of Mongo support.

Maybe that's something our guys could help with in the next couple of months? I realize supporting Mongo means leaving out lots of the code around associations. We've also considered packaging Mongoose and including a flag in our models to let you choose your ORM.

Model.create(attributes).done(callback) (or generate, or add, or new)
Model.find(options).done(callback) (or read, or view, or show, or detail, or findAll)
Model.update(id,newAttrs).done(callback) (or edit, or set, or modify, or update)
Model.destroy(id).done(callback) (or delete, or remove)

[gavri]

I don't have context about any of this. Sorry! I was googling for an answer to something about sequelize and came across this github issue. I then remembered that sequelize in fact does have a way to interface with node style callbacks and so replied.

[mikermcneil]

@gavri @sdepold I love sequelize, and we're going to continue using it for our framework, it's great.

We have two main needs:

• an in-memory database for getting started quickly
• MongoDB support

Is there interest in this on the Sequelize side? I'd be happy to invest some of our resources and my time in helping this happen.

[sdepold]

@mikermcneil wow that sounds greate ! i would pretty much appreciate mongodb support. what do u have in mind about in-memory databases?

[mikermcneil]

The in-memory db is purely for development-- doesn't have to be efficient at all. The idea is that you can get going immediately without having to configure any external database. We'd probably want to start with that, since it's a lower-hanging fruit, and would add a lot of value to our framework and Sequelize. Basically very similar to what these guys are doing: https://github.com/1602/jugglingdb

Then, for Mongo support, I'd think we'd probably want to use Mongoose or some other existing ORM under the covers and map it to Sequelize conventions. Ideally, for emulating relational support via belongsTo/hasMany/hasOne, you'd be able to configure whether associations are handed as links or enclosures, but we might start by just doing links.

We're also interested in adding support for custom mappings for models (adapters). I.e. if you want to build a model to allow CRUD access to Facebook users via the Facebook API, you could write an adapter (i.e. you write FacebookAdapter.find(), FacebookAdapter.create(), FacebookAdapter.updateAttributes(), etc. Originally we had just planned to wrap Sequelize in this sort of abstraction (i.e. our MySQLAdapter, PostgresAdapter, and SQLiteAdapter would use Sequelize under the covers). But If that's something that makes sense to bring down to the ORM level, that would be great, since then it would be available for folks who aren't necessarily using Sails.

Thanks!
Mike

PS- if you have time to talk through this in more depth, it'd be great to Skype for a few minutes to get on the same page. (Ich spreche ein bisschen Deutsch, wenn das behilflich würden.)

[sdepold]

So if you want in-memory db, why not just use SQLite ? You can either use a temporary one via "storage: ':memory:'" or a persistent one via "storage: 'path/to/sequelize.db'. See this for further information: http://sequelizejs.com/#usage-dialects

Sascha Depold
Gesendet mit Sparrow (http://www.sparrowmailapp.com/?sig)

Am Freitag, 2. November 2012 um 22:33 schrieb Mike McNeil:

The in-memory db is purely for development-- doesn't have to be efficient at all. The idea is that you can get going immediately without having to configure any external database. We'd probably want to start with that, since it's a lower-hanging fruit, and would add a lot of value to our framework and Sequelize. Basically very similar to what these guys are doing: https://github.com/1602/jugglingdb
Then, for Mongo support, I'd think we'd probably want to use Mongoose or some other existing ORM under the covers and map it to Sequelize conventions. Ideally, for emulating relational support via belongsTo/hasMany/hasOne, you'd be able to configure whether "joins" are handed as links or enclosures, but we might start by just doing links.
We're also interested in adding support for custom mappings for models (adapters). I.e. if you want to build a model to allow CRUD access to Facebook users via the Facebook API, you could write an adapter (i.e. you write FacebookAdapter.find(), FacebookAdapter.create(), FacebookAdapter.updateAttributes(), etc. Originally we had just planned to wrap Sequelize in this sort of abstraction (i.e. our MySQLAdapter, PostgresAdapter, and SQLiteAdapter would use Sequelize under the covers). But If that's something that makes sense to bring down to the ORM level, that would be great, since then it would be available for folks who aren't necessarily using Sails.
Thanks!
Mike
PS- if you have time to talk through this in more depth, it'd great to Skype for a few minutes to get on the same page.

—
Reply to this email directly or view it on GitHub (#36 (comment)).

[sdepold]

would be great if one could send private messages on github ^^ skype: search for sdepold :)

[mikermcneil]

@ pming on github: F'real. Ill hit you up, thanks!

Mike's phone

On Nov 6, 2012, at 1:21, Sascha Depold [email protected] wrote:

would be great if one could send private messages on github ^^ skype: search for sdepold :)

—
Reply to this email directly or view it on GitHub.

[mikermcneil]

Closing this in favor of #71

[nkrajan]

Its true that Sequelize's promise based interface does not fit well into the testing framework. There is a lot of jumping around and inconsistency while operating based on the callbacks for success and errors. After working with sequelize for almost 2 months then we realized we were deep into trouble. One more problem is the associations. When there are chained associations the output is not consistent. Many times we could not recreate the problems raised by the testers. Now I have taken the pain of migrating to jugglingdb. I hope that the jugglingdb guys can produce more documentation.