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

21–27 of 27 posts

Re: BookShelf, Simple ORM for Node

#21

Post by vectorpush »

nightski wrote: post #13
vectorpush wrote: post #11

Earlier quoted context omitted.

> 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.

Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configuration step to the process.

Re: BookShelf, Simple ORM for Node

#22

Post by vectorpush »

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 actually agree with you and find that writing queries directly gives better performance, is much easier to debug, makes it easier to integrate more advanced database features (like stored procedures or non-standard features like postgres schemas or the jsonb data-type), and avoids the configuration overhead that some ORMs require. In fact, I chose bookshelf precisely because I didn't have to do anything except supply the table name and start CRUDing whereas I'd normally just start writing raw queries in a situation where my goal was to start talking to the database ASAP.

Re: BookShelf, Simple ORM for Node

#23

Post by bpicolo »

vectorpush wrote: post #21
nightski wrote: post #13

Earlier quoted context omitted.

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

Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configurati…

It takes all of seconds to type out a few field names. =/

Re: BookShelf, Simple ORM for Node

#24

Post by setheron »

When I used this back in the day, it was frustrating that the exceptions thrown by BookShelf would be a mismatch of: ValidationErrors, BookShelf errors, database specific errors.

It might be a comment on the JavaScript ecosystem but trying to collate all these myriad of exceptions into a single result to show my user was frustrating.

Re: BookShelf, Simple ORM for Node

#25

Post by nightski »

bpicolo wrote: post #23
vectorpush wrote: post #21

Earlier quoted context omitted.

Ok, but what I'm saying is that I didn't have to enumerate any schema in this case. I understand the benefits of doing so, but it's sometimes desirable to just get something running rather than spend time mapping your ORM to your schema. If I wrote the SQL directly, I also wouldn't need to enumerate my columns in advance, but bookshelf offers some of the conveniences of an ORM without adding an additional configurati…

It takes all of seconds to type out a few field names. =/

Not only that, he actually already is doing this when he accesses those fields in code implicitly.

He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause).

I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.

Re: BookShelf, Simple ORM for Node

#26

Post by vectorpush »

nightski wrote: post #25
bpicolo wrote: post #23

Earlier quoted context omitted.

It takes all of seconds to type out a few field names. =/

Not only that, he actually already is doing this when he accesses those fields in code implicitly. He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause). I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.

> He keeps going on about SQL not requiring it, but SQL requires it in every statement (the select clause).

haha a string of SQL is not the same thing as a type constrained data structure.

> I'd hate to be the one who has to maintain an admin app that could potentially access 230 tables with dynamic column references scattered all throughout the code and no types to keep things in order.

Thankfully, the client used a database that is capable of enforcing type constraints automatically, so I didn't have to spend time writing business logic to reiterate what the database already knows and strictly enforces, in a language that can't even enforce type constraints anyway. Re-declaring your column names and types in javascript literally does nothing except waste time. You shouldn't be reading through your application code to understand the schema of your database, especially when you're dealing with hundreds of tables.

Post reply on HN