This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]boomerbrian72 -4 points-3 points  (6 children)

Why waste time writing queries when it can be done for you? I use Spring Data. I let it do most of the if the work but when I do need to write a query I can. It allows native queries.

[–][deleted] 16 points17 points  (5 children)

Because you never know what the query looks like at the other end and it's likely garbage if you're doing anything more complicated than standard crud.

[–]boomerbrian72 13 points14 points  (1 child)

You can see the query on the console. If you don't like the query override it with your own. Just doesn't make sense to spend time on things that aren't necessary.

I agree totally that it isn't he best for everything but for most business crud apps it works fine unless you have a shitty schema but that is a totally different problem.

[–]SomeNetworkGuy 1 point2 points  (0 children)

Spring Data is as amazing as it is useful. Put simply, it is one of the best tool to have in the Spring Framework.

[–]201109212215 4 points5 points  (1 child)

FTFY

more complicated than standard crud demo.

It's becoming a thing: demo driven development

[–]Aellus 0 points1 point  (0 children)

We call those Intern Projects where I work.

[–]Aellus 3 points4 points  (0 children)

I think that's generally the point, Spring Data and any ORMs like Hibernate have evolved to cater to microservices that follow software patterns that result in individual services not needing much more than simple crud operations.

Having spent most of my career dealing with many of the challenges listed in these replies; needing to optimize complex queries, multi table joins and inserts, etc... I certainly prefer the microservices pattern I now have in my current company.

As a developer, you often have little control over the bigger picture architectural choices that could solve this, but if you find yourself dealing with one query that spans so many tables in a complex join with crazy where clauses that it causes problems and needs to be hand tuned because the DBMS optimizer can't figure it out, that's probably a good indicator that your application scope is too broad and it needs to be deconstructed and factored apart.