4 ms·

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm (http://typeorm.io/ http://typeorm.io/)?

by kapv89 8y ago

eropple 8y ago
I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understanding of PostgreSQL. The code seems fine. But I don't really trust anybody who is that insistent on owning the changes made to my database schema--I am certain it is well-intentioned but it makes me itch. Although I will say that there's an interesting project[1] that creates entities from a database that I need to examine further and see if it's worth using to get around TypeORM's unfortunate primary design goals. [0] - https://github.com/typeorm/typeorm/issues/2453 https://github.com/typeorm/typeorm/issues/2453 [1] - https://github.com/Kononnable/typeorm-model-generator https://github.com/Kononnable/typeorm-model-generator
- tannhaeuser 8y ago
  That's a common pitfall with ORMs and dumb stacks like Spring data: they're made for unexperienced developers who can't be bothered to understand other technology than their favourite programming language. When it comes to databases however, SQL is the standard, is already at a higher level of abstraction than a primitive record-like abstraction build on top of it, and direct SQL access will be required for any meaningful data manipulation at scale, for locking, for schema evolution, BI, etc. anyway.
- loliboli 8y ago
  I’d recommend you to have a look at Objection.js: https://github.com/Vincit/objection.js/ https://github.com/Vincit/objection.js/ Objection.js is an ORM for Node.js that aims to stay out of your way and make it as easy as possible to use the full power of SQL and the underlying database engine while keeping magic to a minimum. ^^ copy+pasted from github
  - eropple 8y ago
    This looks interesting. Some quick thoughts: - I was worried at first because I progressively trust non-TypeScript projects less and less, but the test suite looks fine and they have official typings so there's that mitigation at least. - I really don't love the use of static properties everywhere in order to define model schema. Which is probably a little hypocritical, because one of my own projects[0] does the same thing, but IMO decorators are a cleaner way to do it that reads better to a human. - Require loop detection in model relations is cool. I like that. - In general it's a little too string-y for my tastes. I think `eager()` should take a model class, for example, rather than a string name. Maybe behind the scenes it uses the model class and pulls the string name out of it? But I think using objects-as-objects is a better way to do things than using strings-as-references. Overall, though, it seems very low-magic and I did understand most of it from a five minute peek, so I kind of like this. I think it's a little too JavaScript-y (rather than TypeScript-y) for my tastes, but maybe that can be addressed by layering on a bit of an adapter...I'll need to look deeper. [0] - https://github.com/eropple/taskbotjs https://github.com/eropple/taskbotjs
- pleerock 8y ago
  Its not possible to fit everybody's needs. For some people those design goals unfortunate, for some they are fortunate. And trust me, for 90% people they are fortunate and make their development productive and effective.
- kapv89 8y ago
  You might like my ORM, tabel: http://tabel.fractaltech.in/ http://tabel.fractaltech.in/

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm (http://typeorm.io/ http://typeorm.io/)?

by kapv89 8y ago

"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm (http://typeorm.io/ http://typeorm.io/)?

eropple 8y ago

I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understanding of PostgreSQL. The code seems fine. But I don't really trust anybody who is that insistent on owning the changes made to my database schema--I am certain it is well-intentioned but it makes me itch. Although I will say that there's an interesting project[1] that creates entities from a database that I need to examine further and see if it's worth using to get around TypeORM's unfortunate primary design goals. [0] - https://github.com/typeorm/typeorm/issues/2453 https://github.com/typeorm/typeorm/issues/2453 [1] - https://github.com/Kononnable/typeorm-model-generator https://github.com/Kononnable/typeorm-model-generator

tannhaeuser 8y ago
That's a common pitfall with ORMs and dumb stacks like Spring data: they're made for unexperienced developers who can't be bothered to understand other technology than their favourite programming language. When it comes to databases however, SQL is the standard, is already at a higher level of abstraction than a primitive record-like abstraction build on top of it, and direct SQL access will be required for any meaningful data manipulation at scale, for locking, for schema evolution, BI, etc. anyway.
loliboli 8y ago
I’d recommend you to have a look at Objection.js: https://github.com/Vincit/objection.js/ https://github.com/Vincit/objection.js/ Objection.js is an ORM for Node.js that aims to stay out of your way and make it as easy as possible to use the full power of SQL and the underlying database engine while keeping magic to a minimum. ^^ copy+pasted from github
- eropple 8y ago
  This looks interesting. Some quick thoughts: - I was worried at first because I progressively trust non-TypeScript projects less and less, but the test suite looks fine and they have official typings so there's that mitigation at least. - I really don't love the use of static properties everywhere in order to define model schema. Which is probably a little hypocritical, because one of my own projects[0] does the same thing, but IMO decorators are a cleaner way to do it that reads better to a human. - Require loop detection in model relations is cool. I like that. - In general it's a little too string-y for my tastes. I think `eager()` should take a model class, for example, rather than a string name. Maybe behind the scenes it uses the model class and pulls the string name out of it? But I think using objects-as-objects is a better way to do things than using strings-as-references. Overall, though, it seems very low-magic and I did understand most of it from a five minute peek, so I kind of like this. I think it's a little too JavaScript-y (rather than TypeScript-y) for my tastes, but maybe that can be addressed by layering on a bit of an adapter...I'll need to look deeper. [0] - https://github.com/eropple/taskbotjs https://github.com/eropple/taskbotjs
pleerock 8y ago
Its not possible to fit everybody's needs. For some people those design goals unfortunate, for some they are fortunate. And trust me, for 90% people they are fortunate and make their development productive and effective.
kapv89 8y ago
You might like my ORM, tabel: http://tabel.fractaltech.in/ http://tabel.fractaltech.in/