New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NoSQL database support? #102

Closed
harrywang opened this Issue Nov 18, 2013 · 17 comments

Comments

Projects
None yet
10 participants
@harrywang

harrywang commented Nov 18, 2013

I am not a database expert but want to know whether bookshelf can support NoSQL databases, such as Cassandra and MongoDB. Thanks!

@bendrucker

This comment has been minimized.

Show comment
Hide comment
@bendrucker

bendrucker Nov 18, 2013

Member

It does not support NoSQL. For Mongo, check out the very popular Mongoose.

Member

bendrucker commented Nov 18, 2013

It does not support NoSQL. For Mongo, check out the very popular Mongoose.

@harrywang

This comment has been minimized.

Show comment
Hide comment
@harrywang

harrywang Nov 18, 2013

Thanks. Any future plan to support NoSQL databases?

harrywang commented Nov 18, 2013

Thanks. Any future plan to support NoSQL databases?

@bendrucker

This comment has been minimized.

Show comment
Hide comment
@bendrucker

bendrucker Nov 18, 2013

Member

I'm not a contributor to bookshelf—just started using it for a significant project and so I probably will start. I can say that it's unlikely since SQL is similar across SQLite, MySQL, and Postgres, whereas Cassandra or Mongo will have a total different query language. You'll definitely see some similarities with Mongoose—it has strong and continually improving promise support. It's a higher level tool though—you define schemas with validations and types and then instantiate models from those schemas.

If you're looking for a tool that works across multiple database types, check out jugglingdb or Waterline. Juggling is in active development but the maintainer seems to be totally ignoring issues and PRs. No promise support as far as I can tell. Waterline is a component of the SailsJS MVC framework but you can use it without Sails.

Member

bendrucker commented Nov 18, 2013

I'm not a contributor to bookshelf—just started using it for a significant project and so I probably will start. I can say that it's unlikely since SQL is similar across SQLite, MySQL, and Postgres, whereas Cassandra or Mongo will have a total different query language. You'll definitely see some similarities with Mongoose—it has strong and continually improving promise support. It's a higher level tool though—you define schemas with validations and types and then instantiate models from those schemas.

If you're looking for a tool that works across multiple database types, check out jugglingdb or Waterline. Juggling is in active development but the maintainer seems to be totally ignoring issues and PRs. No promise support as far as I can tell. Waterline is a component of the SailsJS MVC framework but you can use it without Sails.

@bendrucker

This comment has been minimized.

Show comment
Hide comment
@bendrucker

bendrucker Nov 18, 2013

Member

Aside from SQL vs other query languages, the bigger issue is document based vs relational. bookshelf/knex is building joins for relations with foreign keys, whereas Mongo (not familiar with the particulars of Cassandra) can only query from one collection. That means if you have posts with a userId property defined and want a list of posts with the user information included, a Mongo ORM is running one query to fetch the posts, running another to fetch the users that were specified, and then mashing the results together in the ORM. If you find yourself frequently using Mongoose's populate method, you should probably be using a relational DB instead.

Member

bendrucker commented Nov 18, 2013

Aside from SQL vs other query languages, the bigger issue is document based vs relational. bookshelf/knex is building joins for relations with foreign keys, whereas Mongo (not familiar with the particulars of Cassandra) can only query from one collection. That means if you have posts with a userId property defined and want a list of posts with the user information included, a Mongo ORM is running one query to fetch the posts, running another to fetch the users that were specified, and then mashing the results together in the ORM. If you find yourself frequently using Mongoose's populate method, you should probably be using a relational DB instead.

@harrywang

This comment has been minimized.

Show comment
Hide comment
@harrywang

harrywang commented Nov 18, 2013

Thanks!

@tgriesser

This comment has been minimized.

Show comment
Hide comment
@tgriesser

tgriesser Nov 18, 2013

Member

@bendrucker I'm actually working on trying to structure the library so at its core it's based as a generic data-mapper, and could have an interface that (for example) sits on top of mongoose, or level, couch, etc... you just wouldn't have the same relations available. If anyone is interested in helping to take that on, feel free to shoot me an email and I'd love to discuss!

Member

tgriesser commented Nov 18, 2013

@bendrucker I'm actually working on trying to structure the library so at its core it's based as a generic data-mapper, and could have an interface that (for example) sits on top of mongoose, or level, couch, etc... you just wouldn't have the same relations available. If anyone is interested in helping to take that on, feel free to shoot me an email and I'd love to discuss!

@bendrucker

This comment has been minimized.

Show comment
Hide comment
@bendrucker

bendrucker Nov 19, 2013

Member

That's the way juggling does it. There's no question that abstracting away DB specific functionality has some benefit. But in the case of RDBs, the ORM options aren't great (Sequelize) on the MongoDB side though, Mongoose is an excellent library, even if it is massively overused.

I'm all for the strategy of keeping functionality in smaller projects and leaving the developer to structure the project and put together the pieces. Personally I see more need for migrations, schema construction, and validation than another ORM for document databases. Definitely has its place but with Amazon RDS supporting Postgres you might see more devs interested in relational DBs.

Member

bendrucker commented Nov 19, 2013

That's the way juggling does it. There's no question that abstracting away DB specific functionality has some benefit. But in the case of RDBs, the ORM options aren't great (Sequelize) on the MongoDB side though, Mongoose is an excellent library, even if it is massively overused.

I'm all for the strategy of keeping functionality in smaller projects and leaving the developer to structure the project and put together the pieces. Personally I see more need for migrations, schema construction, and validation than another ORM for document databases. Definitely has its place but with Amazon RDS supporting Postgres you might see more devs interested in relational DBs.

@tgriesser

This comment has been minimized.

Show comment
Hide comment
@tgriesser

tgriesser Nov 19, 2013

Member

Personally I see more need for migrations, schema construction, and validation than another ORM for document databases.

For sure, schema construction can be done for the most part with knex, migrations for those in knex are also just about there, and I also hope to wrap up in the next week or two the checkit library for a nice validations solution that can be easily integrated. Better type-handling is also on my short list.

That's the way juggling does it. There's no question that abstracting away DB specific functionality has some benefit.

So my ultimate goal with all of this is to structure the library so other libraries mix well with it and everything is nicely layered on top of one another.

So the Bookshelf core interface of save, destroy, fetch is the generic base which currently pulls in Knex & a SQL specific adapter (which does all of the nice relation stuff)... and even that can be built on top of, with say a nice active-record static interface which is next on my todo list after the above stuff I mentioned...

But I'd like to make it so one could just as easily write adapters written for other databases so say a "user" in a postgres row could hasMany mongodb documents and that'd just work. That's a bit further off but I think it'd be a neat goal to keep in mind.

Definitely has its place but with Amazon RDS supporting Postgres you might see more devs interested in relational DBs.

Yeah, absolutely agree... my core focus is on building a solid foundation for relational db's, the other stuff would be nice to have down the road.

Member

tgriesser commented Nov 19, 2013

Personally I see more need for migrations, schema construction, and validation than another ORM for document databases.

For sure, schema construction can be done for the most part with knex, migrations for those in knex are also just about there, and I also hope to wrap up in the next week or two the checkit library for a nice validations solution that can be easily integrated. Better type-handling is also on my short list.

That's the way juggling does it. There's no question that abstracting away DB specific functionality has some benefit.

So my ultimate goal with all of this is to structure the library so other libraries mix well with it and everything is nicely layered on top of one another.

So the Bookshelf core interface of save, destroy, fetch is the generic base which currently pulls in Knex & a SQL specific adapter (which does all of the nice relation stuff)... and even that can be built on top of, with say a nice active-record static interface which is next on my todo list after the above stuff I mentioned...

But I'd like to make it so one could just as easily write adapters written for other databases so say a "user" in a postgres row could hasMany mongodb documents and that'd just work. That's a bit further off but I think it'd be a neat goal to keep in mind.

Definitely has its place but with Amazon RDS supporting Postgres you might see more devs interested in relational DBs.

Yeah, absolutely agree... my core focus is on building a solid foundation for relational db's, the other stuff would be nice to have down the road.

@bendrucker

This comment has been minimized.

Show comment
Hide comment
@bendrucker

bendrucker Nov 19, 2013

Member

The mixing of DBs is really cool. Never would have thought of that but I can totally see use cases.

Member

bendrucker commented Nov 19, 2013

The mixing of DBs is really cool. Never would have thought of that but I can totally see use cases.

@rizidoro

This comment has been minimized.

Show comment
Hide comment
@rizidoro

rizidoro Nov 19, 2013

Yeah , +1 for mixing DBs =D

rizidoro commented Nov 19, 2013

Yeah , +1 for mixing DBs =D

@Karnith

This comment has been minimized.

Show comment
Hide comment
@Karnith

Karnith Jun 21, 2016

hi, is there any update on this?

Karnith commented Jun 21, 2016

hi, is there any update on this?

@vineey

This comment has been minimized.

Show comment
Hide comment
@vineey

vineey Jul 30, 2016

+1 Would really love to see this future, really really need this!

vineey commented Jul 30, 2016

+1 Would really love to see this future, really really need this!

@DObD

This comment has been minimized.

Show comment
Hide comment
@DObD

DObD Jun 17, 2017

It has been a while, and I see this is still open. Am curious if there has been any further thought towards the DB mixing thoughts.

DObD commented Jun 17, 2017

It has been a while, and I see this is still open. Am curious if there has been any further thought towards the DB mixing thoughts.

@richenlin

This comment has been minimized.

Show comment
Hide comment
@richenlin

richenlin Jun 23, 2017

I made a similar attempt based on knex.js, welcome you to provide valuable advice, thanks

repo: https://github.com/thinkkoa/thinkorm

richenlin commented Jun 23, 2017

I made a similar attempt based on knex.js, welcome you to provide valuable advice, thanks

repo: https://github.com/thinkkoa/thinkorm

@DObD

This comment has been minimized.

Show comment
Hide comment
@DObD

DObD Jun 23, 2017

@richenlin I will definitely look this over...

DObD commented Jun 23, 2017

@richenlin I will definitely look this over...

@dj-hedgehog

This comment has been minimized.

Show comment
Hide comment
@dj-hedgehog

dj-hedgehog Jul 19, 2017

Contributor

The project leadership of Bookshelf recently changed. In an effort to advance the project we close all issues older than one year.

If you think this issue needs to be re-evaluated please post a comment on why this is still important and we will re-open it.

We also started an open discussion about the future of Bookshelf.js here #1600. Feel free to drop by and give us your opinion.
Let's make Bookshelf great again

Contributor

dj-hedgehog commented Jul 19, 2017

The project leadership of Bookshelf recently changed. In an effort to advance the project we close all issues older than one year.

If you think this issue needs to be re-evaluated please post a comment on why this is still important and we will re-open it.

We also started an open discussion about the future of Bookshelf.js here #1600. Feel free to drop by and give us your opinion.
Let's make Bookshelf great again

@juan-g

This comment has been minimized.

Show comment
Hide comment
@juan-g

juan-g Jul 21, 2017

Since the new MEAN stack (MongoDB, Express.js, AngularJS, and Node.js) is now widely considered the main alternative to the traditional LAMP stack (Linux, Apache, MySQL, and PHP), in my opinion it would be very useful for many if MongoDB, the most popular NoSQL database, were supported by Bookshelf.js, an excellent Node.js ORM.

juan-g commented Jul 21, 2017

Since the new MEAN stack (MongoDB, Express.js, AngularJS, and Node.js) is now widely considered the main alternative to the traditional LAMP stack (Linux, Apache, MySQL, and PHP), in my opinion it would be very useful for many if MongoDB, the most popular NoSQL database, were supported by Bookshelf.js, an excellent Node.js ORM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment