17 ms·
Show HN: A new way of ORM in Java
- crummy 6y agoHow does this compare to ActiveJDBC? Features look similar, with slightly more Java-ish queries
- an_opabinia 6y agoHow do you feel about JOOQ?
- sushshshsh 6y agoRepeat after me... CSV! CSV! CSV!
- ccleve 6y agoI wrote a package that took a different approach: just enough code to get rid of the JDBC boilerplate, but not enough to get in the way of using SQL: https://github.com/dieselpoint/norm https://github.com/dieselpoint/norm Blog post on it: https://blog.dieselpoint.com/a-minimalist-good-enough-approach-to-object-relational-mapping-64df9798b276 https://blog.dieselpoint.com/a-minimalist-good-enough-approa...
- blackrock 6y agoWhy is ORM better than just writing out SQL code? It just adds an extra layer of indirection, and another layer of processing that can go wrong. And when things go wrong, you have to dig down to the SQL level to understand it. But the table names are all mangled, which might further add to the complexity of debugging it.
- deleted 6y ago[deleted]
- geocar 6y agoWhat if things don’t go wrong? One way that it is better is that it might be a better abstraction. If so, it would be possible to implement just these methods to target an in-memory or on-disk store without the SQL — and get a dramatic performance improvement. But because data management requires a lot of disciplines and it is easier to test “is this is a better abstraction?” if by creating these kinds of abstractions on abstractions. Some of them will evolve into “noSQL” but most fail because SQL has a first-movers advantage and they aren’t enough better to warrant further investment. Better may be possible but too few people can afford the luxury of exploring language design — and those that can are scared off easily; People who make bad investments worry about their fellow human and try to prevent them from making the same mistake; and so you worry about what happens when it goes wrong, which is why I say, “what if it doesn’t?”
- desas 6y agoDo people actually use ORM to avoid writing SQL (there are other patterns for that), or do they use it because it saves writing the boilerplate of object hydration?
- braisdom 6y agoIt is a more efficient way to data analysis, SQL is just one way, Java is another way, and ObjectiveSQL, instead of using Java instead of SQL, let's forget about SQL
- BorisTheBrave 6y agoThe biggest deal for me is type safety (I use C#'s EntityFramework). While composing the ORM queries, I get the benefit of static verification, autocompletion, and can avoid the common boilerplate of joins. When reading code, find-references and so on work.
- chrismsimpson 6y agoBite the bullet and install Neo4j
- EdwardDiego 6y agoIsn't that a graph db?
- snicker7 6y agoNeo4j's marketing asserts that is more natural to model applications with a graph database, sidestepping the object-relational mismatch.
- valenterry 6y agoStop using ORMs already. We now have at least a decade of experience with them and found out that they are a suboptimal solution to the problem. Just use JOOQ or any other kind of library that removes the boilerplate and is 100x more maintainable and productive.
- coding123 6y agoStop using SQL already. We now have at least 4 decades of experience with them and found out that they are a suboptimal solution to the problem. Just use an ORM or any other kind of library that removes the boilerplate and is 100x more maintainable and productive. See how useful it is to not explain anything.
- valenterry 6y agoMy post is provocative and not explaining, true. However, your comparison does not make sense. JOOQ and similar libraries don't make you write SQL, even if their API is closer to SQL than what most ORMs do. If you replace "ORM" in your example with NoSQL or some other technology that directly competes with SQL then it would make sense.
- DJBunnies 6y agoI've never seen an orm work 100% correctly though, with indexes/pagination/etc. Far easier to write correct sql than to convince the orm how to form correct sql.
- pantelisk 6y agoORMs seem amazing up until the inevitable point of hitting a performance issue or bug, and having to print the underlying statement. At that point you are no longer fighting with the bug impacting your systems, you are fighting with the ORM midddle-ware it self, and having to quickly improve your SQL competency above everything else. That is the moment you 've lost all the benefits advertised. For smaller systems it might be ok I guess, but stay alive long enough and you 'll see that sooner or later every small system desires to grow, grow and grow!
- superyesh 6y agoHow about joins? Thats usually where things get tricky. Don't see it in the README, so probably missing something?
- neeleshs 6y agoSimilar to https://github.com/activejpa/activejpa https://github.com/activejpa/activejpa?
- jacktasia 6y agoI've been looking for something like this for a while and it is quite nice so far. I was able to wire it into a side project very quickly and remove a lot of boilerplate.
- pieterb8 6y agoMany Java developers say ORMs are the problem. Not so. JPA is. It is complicated, has lots of implicit behaviour, has a really bad query language and is horrible to optimize. It is why you never hear 'ORMs are horrible' from ruby on rails or elixir developers: they have a proper ORM! Actually Java has too, and probably several - Ebean, for example, solves all of the complexity problems, adds a query creation tool that stays very close to SQL and allows very simple object fetching, allows for simple batch operations, and requires a proper explicit save instead of the complicated implicit JPA one.
- nesarkvechnep 6y agoTo be honest, Ecto is not an ORM, it's a query builder with superpowers. More so Elixir is a functional language and technically the O in ORM is missing. I love Ecto, I've never seen something as easy to use and maintain but it's not something Java folks would call an ORM.
- pieterb8 6y agoTrue indeed, certainly not an ORM. But I would say the effect you can achieve with it is very close to what a proper ORM can do, much more so than the lower level frameworks java people are now recommending.
- seer 6y agoNot a java developer myself, but as a longtime coder and even an author of an ORM I can relate. I think ORMs just bridged that gap of “how my objects look in code” and “how to store them” quite well. But lately we’ve been removing a lot of the reasons to use ORMs altogether. By using more functional languages and features, we’ve been getting rid of that “O”. By adding more relationship features to databases like jsonb in postgres, and even nosql dbs themselves, we’ve been removing the “R” bit as well. There’s simply a log less for ORMs left to do in modern codebases. I’ve personally been using only raw sql with some help for building complex queries - in the JSX way of embedding stuff into the query as opposed to query builders that build it altogether, and couldn’t be happier. With migrations handled by a separate library, all the db connection lib has to do is handle pools and run queries. I’ve been looking into software that would statically type the sql queries themselves, which could end up as a way better dev experience. ORMs helped there too by giving you some piece of mind that what you wrote was correct with regards to the DB schema, but that was only true if no other tool touched your db. But that is very hard for sufficiently large systems, especially in the era of microservices. With typed sql queries it’s no longer necessary, and is even safer.
- valenterry 6y agoI think your post summarizes it pretty well. One more addition from my side would be to emphasize that "immutability by default" has been accepted as best practice, which does not really work well with with original idea of ORMs.
- shashurup 6y agoIMHO, ORM solves wrong problem. I don't see the mapping itself as a problem - in almost any language there are data structures which can represent data we query from db. The ability to map a table record to an instance of some class looks like a good idea initially. But with time you find yourself in the situation where you need to query only a subset of fields and you end up with several implicit contexts with its own set of accessible fields each. The real problems are: 1. Boilerpalte we get in the code which extract query results. This issue is not universal. Psycopg in Python produces a lot less boilerplate than, for instance, JDBC. This problem is a lot more visible in statically typed languages. 2. Boilerplate we get creating queries. Conditionally turning part of queries on and off produces a lot of code. This is mostly due to SQL syntax being more friendly to human rather than machine. Infix logical operators in conditions, commas etc., makes it hard to write code which generates SQL. 3. SQL is not good at reusing query parts. Views don't solve all problems. The first problem is better to solve with code generation at compile time making it possible to perform all kinds of type check etc. Generating SQL is not that easy without introducing some kind of intermediate language which is more code friendly. I think some kind of templating could solve the problem so that it would look essntialy like SQL but with ability switch part of the query on and off. The hardest part is reuse which I don't know how to address. For instance, adding a join to some ACL table with conditions to exclude entities the client is not authorized to access.
- nextaccountic 6y ago> For instance, adding a join to some ACL table with conditions to exclude entities the client is not authorized to access. This specific thing is better done with row-level security (in postgres at least). This requires that each user have a role in the db and that all queries be done in transactions that switch to the relevant role; but this seems to be a best practice anyway.
- ivan_gammel 6y agoI cannot imagine this as a best practice, given that you will have to synchronize two identity and access management systems - the one on the frontend and the one in Postgres. Compared to ACL or filtering of results in the service tier via something like Spring Security, it’s too much overhead for such task.
- lukaseder 6y agoIt's a start :)
- braisdom 6y agoSQL is more human friendly, but less programming friendly. In programming, SQL will be changed in response to your business, if it's just a string, it would be a disaster for programming
- braisdom 6y agoSo, I overloaded the Java operator to achieve the equivalence of the two
- braisdom 6y agoMore than just for complex SQL, ObjectiveSQL is also very user-friendly for simple queries. For example: queryByPrimaryKey query(predicate, params) ... https://github.com/braisdom/ObjectiveSql https://github.com/braisdom/ObjectiveSql
- braisdom 6y agoObjectiveSQL is an ORM framework in Java base on ActiveRecord pattern, which encourages rapid development and clean, codes with the least, and convention over configuration. Features Dynamic code generation with JSR 269 for Java API of database access Full Java API of database access without coding Dynamically SQL programming with Java syntax, and very close to SQL syntax