Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BookShelf, Simple ORM for Node

github.com

Post reply on HN
Print view View original

11–20 of 27 posts

Re: BookShelf, Simple ORM for Node

#11

Post by vectorpush »

nightski wrote: post #7
vectorpush wrote: post #5

Earlier quoted context omitted.

On the other hand, this behavior is quite nice if you want to quickly build something around an existing database and you don't really want to spend time reenumerating the entire schema in code before being able to leverage the ORM.

Meh you essentially are re-enumerating it though, every time you access a field. There is an implicit contract being built up by the code written. I don't find that creating types to make this contract explicit takes much time at all, and there are significant benefits. Unfortunately it simply isn't an option in JS (maybe one could with TypeScript).

> I don't find that creating types to make this contract explicit takes much time at all

This depends on the complexity of your schema. In my case, I was dealing with a 230 table legacy application where some of the tables had as many as 70 columns. I was tasked with building an ad-hoc administrative tool for the owners so that they could perform a few specific tasks and periodically review some information in the system.

I wanted to use an ORM because I didn't want to write a bunch of boilerplate SQL to rig up a tedious but relatively simple internal CRUD app. With that in mind, it certainly didn't make sense to enumerate the details of every column when the alternative (raw SQL) also wouldn't require me to do that. Enumerating explicit column information was unnecessary and certainly would have taken me a lot of time.

Re: BookShelf, Simple ORM for Node

#12

Post by jadengore »

bpicolo wrote: post #3

My biggest problem with bookshelf is that it automatically grabs column names, so you don't (by default) have any representation in code of what the dang model looks like. Since JS is not typed, this can lead to a lot of having no idea what might be going on unless you wrote the code yourself

It's definitely a tradeoff that has led to some problems. However, I think it's important to remember Bookshelf's flexibility, and that the tradeoffs are more language-level than library-level.

Re: BookShelf, Simple ORM for Node

#13

Post by nightski »

vectorpush wrote: post #11
nightski wrote: post #7

Earlier quoted context omitted.

Meh you essentially are re-enumerating it though, every time you access a field. There is an implicit contract being built up by the code written. I don't find that creating types to make this contract explicit takes much time at all, and there are significant benefits. Unfortunately it simply isn't an option in JS (maybe one could with TypeScript).

> I don't find that creating types to make this contract explicit takes much time at all This depends on the complexity of your schema. In my case, I was dealing with a 230 table legacy application where some of the tables had as many as 70 columns. I was tasked with building an ad-hoc administrative tool for the owners so that they could perform a few specific tasks and periodically review some information in the sy…

Sounds like a poor ORM. I've never had to enumerate the entire schema, just the tables/columns I actually utilize in code.

Re: BookShelf, Simple ORM for Node

#14

Post by scandox »

untog wrote: post #6

I was battling with Sequelize JS for a long time, then discovered Bookshelf. A breath of fresh air, it works so much better. Plus, the underlying library (Knex) is also fantastic for raw queries, migrations, etc.

I'm also curious what your problems were. I'm using it at present and haven't run into anything worrying...yet

Re: BookShelf, Simple ORM for Node

#16

Post by underbluewaters »

untog wrote: post #6

I was battling with Sequelize JS for a long time, then discovered Bookshelf. A breath of fresh air, it works so much better. Plus, the underlying library (Knex) is also fantastic for raw queries, migrations, etc.

Same here. Sequelize looks nice on the surface, but I've found its documentation to be atrociously out of date. Bookshelf has less features but works better in practice.

Re: BookShelf, Simple ORM for Node

#18

Post by untog »

scandox wrote: post #14
untog wrote: post #6

I was battling with Sequelize JS for a long time, then discovered Bookshelf. A breath of fresh air, it works so much better. Plus, the underlying library (Knex) is also fantastic for raw queries, migrations, etc.

I'm also curious what your problems were. I'm using it at present and haven't run into anything worrying... yet

I didn't have problems as such with Sequelize, it was just a lot more difficult to work with than Bookshelf. And it's been about two years so I don't remember the details, sorry.

Re: BookShelf, Simple ORM for Node

#19

Post by tracker1 »

vectorpush wrote: post #5
bpicolo wrote: post #3

My biggest problem with bookshelf is that it automatically grabs column names, so you don't (by default) have any representation in code of what the dang model looks like. Since JS is not typed, this can lead to a lot of having no idea what might be going on unless you wrote the code yourself

On the other hand, this behavior is quite nice if you want to quickly build something around an existing database and you don't really want to spend time reenumerating the entire schema in code before being able to leverage the ORM.

Honestly, if I know what the database looks like, I'd rather use babel with string templates for building parameterized queries against the database directly. [1] [2]

It seems to me that the layers of ORM (in JS) don't really buy you much more than some simple validation wrappers and a simpler client for SQL queries. After having used a number of ORMs in static environments (mostly C#), I'm much more inclined to prefer a simple SQL client that's easier to make direct SQL queries in than having an ORM in a system that actually complicates things. It'd be one thing if an ORM generated typescript so that you would get auto-complete in your editor/ide, but I don't see much point to this. I'm not a huge fan of typing in JS/TS, but I could at least see the value to some in that case.

[1] https://github.com/felixfbecker/node-sql-template-strings

[2] https://github.com/tracker1/mssql-ng

disclaimer: I wrote mssql-ng and used it for a lot of data migration/manipulation scripts and it was a joy to use with async/await syntax.

Re: BookShelf, Simple ORM for Node

#20

Post by mkozlows »

tracker1 wrote: post #19
vectorpush wrote: post #5

Earlier quoted context omitted.

On the other hand, this behavior is quite nice if you want to quickly build something around an existing database and you don't really want to spend time reenumerating the entire schema in code before being able to leverage the ORM.

Honestly, if I know what the database looks like, I'd rather use babel with string templates for building parameterized queries against the database directly. [1] [2] It seems to me that the layers of ORM (in JS) don't really buy you much more than some simple validation wrappers and a simpler client for SQL queries. After having used a number of ORMs in static environments (mostly C#), I'm much more inclined to pref…

I agree with you that ORMs don't add a whole lot of value to Node, but I think there's still value in slightly-higher-level libraries.

Like, doing a simple `select whatever from table where x = ? and y = ? and z = ?` is annoying with a string-based query builder when those parameters are optional, sousing something like Knex where you can just pass in a hash of field/value pairs for the criteria for your where clause is a big win.

Post reply on HN