Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
At my work place, we use DAO pattern to hancle any sort of database operation. It hides bulky statements from programmer. Programmers need to write sql query and logic to handle output data. BaseDao handles all sort of operation and return output in required format.
I found that this class is not perfect. I added the code to control number of connections and to handle connection issues like slow connectivity, no connectivty, number of atttempts for connection etc.
But I would have to add more code to support advance feature of JDBC like providing/accessing binary data, Handling resultsets returned from SPs etc.
Is there any Java Framework or group of classes which can cover many of the database operations?
Please suggest.
I think that you are looking for Java Persistence API. It's a Java EE specification and Hibernate is the most popular implementation.
You could try Spring DAO instead. They have a nice template pattern for handling resultsets.
Or you can take another step step back away from JDBC and use Hibernate.
Spring Data JPA does even more abstraction than the other suggestions people have made. With that and Hibernate you don't even need to write queries unless it's a complex operation you need to perform.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
What is the Best way to convert Uppercase values to camel case.
Lets say I have API with response {"name":"VIRAT KOHLI","teams":"RCB INDIA DELHI"}
Should it be handle at DB query level or Java level (Business logic) or at Client-side like using Angular pipes. What is the best practices and what is best in terms of performance ?
At database I am using simple JDBC query.
So I don't think there's a huge difference in performance or speed.
However, if you are working with a very large amount of data, doing the conversion at the database level could add a little bit more time.
It all depends on your context but you can :
Do it by Angular using the "TitleCasePipe"(https://angular.io/api/common/TitleCasePipe#titlecasepipe)
or
avoid repetition by doing a ".map()" on the received data by putting in camelCase the concerned fields (there are a lot of examples out there).
Do it on the Business layer of your Backend just making sure to do the transformation before sending the response.
Finally do it from the database (not recommended) but you have to take into account that the code is always faster than a database query.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have difficulty in implementing GraphQL in a java project as a part of updating it. I'm trying to connect an entity (which uses the Hibernate ORM to map to different databases) to a GraphQLObjectType . Any suggestions how can I accomplish this? Can I omit the GraphQL database configurations if so?
There're multiple options here.
It's probably best to not even map an entity directly . Entities are direct representations of the DB and, as such, should probably not be directly exposed, but wrapped into DTOs (maybe allowing pagination, flattening relations, or whatever is appropriate) instead.
If you just need to map the class (entity or not) to a GraphQLObjectType, graphql-java-annotations is the simplest (and most limited) route (check the status of this project first, it was on a hiatus for a while)
If you want to expose the entire entity graph through GraphQL, graphql-jpa might be your best bet (as Sriram suggests), as it's intended to do exactly that, while also adding pagination, aggregation and sorting
If you want to automatically expose not only an entity/DTO class, but also the operations upon it (e.g. an arbitrary service class), look at graphql-spqr (I'm the author of that project)
If you already defined your entities using JPA/Hibernate, try this:
https://github.com/jcrygier/graphql-jpa
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a query which returns thousands of records (at some point it will). In that query I have some like this
Case when column in(:params1)
then :param2
when column in (:params3)
then :param4
when column in(:params5)
then :param6
when column in(:params7)
then :param8
END ABC
Now the question is what is better to do this in the query or return the column value and do the if\else in the pojo? And why? I tried testing it but currently don't have that much data.
Usually it is better (both because of performance and complexity) to let the database do as much work as possible for you. Doing the work in your application is likely to incur more network traffic than is necessary (which would decrease performance) and the code would have to contain all the nasty logic in it which would add complexity.
Also remember to avoid premature optimization. Try to avoid fixing problems that you don't have yet.
I would recommend letting the database do the work.
Returning thousands of records to the middle tier, operating on them, and shoving the result back into the database makes no sense to me. Why do all that network back and forth?
If you are truly processing that many records, I'd recommend considering letting the database do the work. No network traffic that way.
If not possible, you should make sure you truly need all those records. I'm betting you only think you do.
Writing queries this way seems like another bad idea to me.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to cassandra. I have to write an application that uses cassandra. I wanted to know which one will be better for me so that i will not face much problem in future. Which api should i use for my application.
Sunil, you're addressing a reasonable question, and I think it's wholly appropriate that you've asked it before coding away at a problem. You might reach a more widely accepting audience if it were phrased something like, "What are the pros and cons I should look for between these two approaches to help me decide between them?"
The Hector client supports a programmatic interface for communicating with Cassanda, as well as a way to parse CQL statements, so your choice isn't necessarily between Hector and CQL, but more like programmatic vs. CQL, or a combination of the two. You could face that same question even if choosing between Hector and Astyanax clients.
Reasons to choose CQL:
CQL is easy to store, retrieve, and compare revisions.
CQL is easy to read and reveiw, especially as DDL.
CQL is easy to log for troubleshooting and auditing purposes.
Developers with a history of RDBMS may acclimate more quickly to CQL, reducing training time or increasing a pool of candidates for hire.
Community development is trending toward JDBC-like handling of CQL.
Reasons to choose Programmatic:
[AMENDMENT]
It appears some of my knowledge was outdated. Based on jbellis' comment (the Jonathan Ellis, I presume), CQL is currently more performant than thrift, and also supports prepared statements. I'm at a loss for a good argument against a CQL-based approach.
Another completely different option is playOrm so that you can do joins with no limitations. playOrm allows you to do "scalable JQL" which looks like the below. You only need to decide how to partition your data.
#NoSqlQuery(name="findJoinOnNullPartition", query="PARTITIONS t(:partId) select t FROM TABLE as t INNER JOIN t.security as s where s.securityType = :type and t.numShares = :shares")
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
What is the general guideline/rule for filtering data? I am accustomed to seeing filters in an SQL statement in the WHERE clause, although there are occasions that filters introduce complexity to the SQL, making it massive and abit hard to read on first glance for intermediate developers, but well-written ones that look complex are well-tuned and optimal. Filtering can also be done in Java, but that of course has a drawback where unfiltered data from SQL can be huge and loading it in memory only to filter it out may be wasteful. Of course there are cases where you have no choice but to filter in Java if you have several datasources as dependencies that the filter requires.
Filter on the backend (sql), whenever possible. If that makes the query too complex for a junior developer then so be it. While clarity of code is important, you shouldn't make design decisions based on how well a junior developer will understand it -- its sufficient that he be able to use it.
This is particularly the case when talking about different layers, your junior developer might not know any SQL, would you then avoid a SQL backend entirely?
Write your SQL to be as clear as possible (without sacrificing performance), but do so with the expectation that the person maintaining it will be familiar with SQL and how it should be used. When crossing layers like this, a little "easier to understand" can really kill your performance (pulling data back from the db in order to update it, can take thousands of times longer than a update on the DB, inappropriate use of a cursor can be expoentally worse than a set based solution).
If the data is already in the DB, then it makes more sense to do the filtering within it, since the RDBMS will be optimized for this kind of work. If the filtering can be confusing to novice and intermediate developers, why not hide it in a view, and only grant access to the view, to the users in question?
I guess there are no definite answers to it. It depends of individual use case. Both filtering in java as well as SQL can be applicable depending on the application under consideration.
As you mentioned, filtering in SQL can make the queries complex and and costly. But at the same this can be improved using database tuning, putting appropriate indexes, table partitioning etc. This is specially the case where in the database design is still evolving and you can do these type of changes.
if you are working on a system whose database is already designed and you have hardly any scope for significant changes (and hence not much query/database optimization), in this case filtering in java is better option.
It all depends on specific use case.