I am currently learning spring data can anyone explain what the difference between them #NamedQuery vs #NamedNativeQuery and When to use them?
Can we use native SQL in #NamedQuery?
#NamedQueryis for writing your queries in JPQL, the standard query language of the JPA standard. This is the default and you should stick to these queries whenever possible, because they are independent of the exact DBMS which you use.
#NamedNativeQuery on the other hand is for writing native queries (in SQL) which potentially can be DBMS specific.
It is a tradeoff. #NamedQuery gives you portability because you stick to the standard. #NamedNativeQuery gives you flexibility but you leave the standard and potentially lose portability. In case you switch to another DBMS, it is likely you would need to rewrite some of your #NamedNativeQuery definitions.
So we should only use #NamedNativeQuery if it is really necessary.
#NamedNativeQuery is for writing SQL query, while #NamedQuery is for writing HQL query.
So in your case, for writing native SQL query you would be needing #NamedNativeQuery.
However, be aware that writing native SQL will make your application less flexible and a portability nightmare because you are tying your application to work only for a particular database. If you are absolutely sure that you won't be needing to migrate to a different database, then this might not be a big concern for you. Otherwise prefer native HQL over native SQL.
Related
I need to execute some T-SQL code in Java. I would be glad if it was possible in Spring.
I have an ERP system, that is a little bit old, and some tasks we need to perform some T-SQL code, call a lot of procedures etc. The codes has about 200 lines. We want to automate it.
Can I execute native SQL lines in Java. I mean just pass SQL statements that I execute in SQL Management Studio. I read about JdbcTestUtils, but it's deprecated.
Isn't it any other solution for that?
Two thoughts come to mind. JdbcTemplates and Native Queries.
Spring provides an abstraction over JDBC called JdbcTemplates. With JdbcTemplates, you can execute any arbitrary SQL and organize the results into lists and objects. This is not really tied to JPA though.
Within JPA, you can use Native Queries. This is slightly more oriented to marshalling data back into Entities so if that what you are interested in, it might be a better choice. And you can execute named queries with the same EntityManager that JPA provides.
I am starting a Research project that involves evaluating the execution costs in each branch of the query execution plan and given a big data set the program would re write the query execution plan so that the query can be executed in certain time bounds.
I have experience with java and oracle but i have no prior experience with NoSql databases, I do have alot of options as of Pig, Casandara, CouchDB that i read initially.
My question(s) are as follows:
Can i reorder the query execution plan in oracle using JDBC?
What is the best option to do such kind of project (may be the most
supportive DBMS)?
The query execution plan is part of the DBMS Logic to execute you declarative SQL wishes.
When your throw you SQL queries against a SQL Server, there is a phase where your query gets "optimized" to run the underlying functions (which and when). SQL is just a way to let the DBMS know, what you want.
What I understand from you question is, that you would like to have a tool to "pre"-optimize your query. Qracle and DB2 have some neat tools to do this, either in production, analyzing the incoming queries, or before, using tools provided by the vendor.
Because of SQL being a declarative wish thingy, you can optimize you queries, by minimizing the amount of data to be looked up. Use the with statement in Oracle to process only a portion or sub-query statements in DB2. Do not use sub-queries in MySQL. Avoid to many and statements in postgreSQL, use in instead.
Since the query execution plan is part of the DBMS you use, you have to buy your DBMS a drink first, before you can get all wild and optimized ;)
I don't think there are things like Oracle Hints for NoSql queries. In addition (at least MongoDB) do not support joins, so there is much less space to optimize queries since they always act on a single collection.
What e.g. MongoDb supports is indexing of properties to optimize search queries based on them. But whenever you need some kind of Joins you will fire two requests for it.
Maybe it's also worth to take a look on mongos Aggregation mechanism. Thats where you can handle aggregations on server side (still on single collections only). But even there I don't see much space to optimize queries before they get to the DB.
The explain operator gives further information about debugging and optimizing mongoDB queries.
Some more about optimizing MongoDB
how to prevent my website from doing sql injection in it
I am working using Struts 2 , DB MY sql .
The best way I think is to not re-invent the wheel and use the tools already available. For a small project I would recommend to simply use prepared statements when querying your database.
http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html
You could also look into using an ORM like Hybernate. But make sure to use it as intended. Even HQL can be susceptible to injection. See: how much safe from SQL-Injection if using hibernate
The important thing is to not write your own native queries by concatenating query strings with values from untrusted sources.
Hi I am a newbie using persistence API, and have also read few posts related to the same and got a very few understanding between these two. the below post really helped me clear my concepts for #NamedQuery
What is a named query? I now wanted to learn all the important key differences between NamedQuery and NamedNativeQuery, and which one is preferred most while dealing with JPA-QL, and performance wise.
Thanks!
A native query isn't JPQL. A regular query is converted by the persistence provider into something the underlying persistence system understands (such as SQL SELECT, or a NoSQL retrieval). A native query, while not portable, is written directly in the native language of the store so that you can use special features (like PostgreSQL's IP address manipulation) at the cost of portability.
I want to write Java code to work with a database, no matter which database is used. My problem is that it wouldn't be Object related. There are some insertions and queries that are but most of them aren't.
Right now we are using Postgresql and pure JDBC, but we may have to make it work with Oracle.
Can Hibernate (which I've never used) solve my problem or should I go for something else ?
I have created jOOQ precisely for that. jOOQ models SQL itself as a domain-specific language in Java. It embraces using standard and vendor-specific features, such as built-in functions, window functions, stored procedures, hierarchical queries, etc. Whenever possible, a vendor-specific functionality from one database is simulated for other databases. That way, most of jOOQ-generated SQL is compatible with any of its 13 supported databases.
See also this related question here:
ORM frameworks used for insert only / query only apps
I like #unludo's JPA answer but I thought I'd add some additional details.
I would recommend changing your code to use persistance interface that you define.
public interface DataPersister {
public void saveFoo(Foo foo);
public void findFooById(int id);
...
}
Your first implementation of the interface would then be using JDBC/Postgresql. If you want to use JPA under the covers then fine. Or if you want to switch to some no-SQL database or even flat files then fine.
Once you have the separation in your own code between the usage of the data and the persistence implementation, then it is significantly easier to switch to a different persister. You can use a cheap database like H2 for testing and switch to Postgresql in production while migrating to a new database in the near future.
Hope this helps.
Problems with Hibernate is that you need to modelize your relational database like object model. Sometimes this make difficult working with existing database. So it depends your relational database.
Other framework (not JPA) is Ibatis. Try to look at this framework.
The standard for Java is JPA and it is very powerful. Hibernate is the industry standard as a JPA provider.
JPA helps you write a clean persistence layer. You may write queries which are sure not to break, because they are validated at compilation time. I like to use spring for this, it's so easy to unit test. But CDI now provides the same I believe.
It's also easy to write test classes. As a coworker once teached me, the model is the most important thing you have. You don't want it to break or you have problems.
With JPA you may also generate the schema from the entities, for any database you want to use. From experience, it's also very good.
JPA helps you put good practices at work. That's a lot of value.
Regarding #hvgotcodes answer, yes you have to be careful with the cost but you may also mix jdbc and jpa. That's what Dao's are for.
The problem with writing your own sql is you need to manually optimize it for your RDBMS. Some RDBMS support varying sql constructs.
So you need to balance that against the overhead of switching to an ORM based solution. Or, make sure you sql is 100% standard so you don't use any constructs that work in one RDBMS solution and not in another.
In your particular situation, it's probably going to be easier to just fix your sql than rework your entire persistence layer to use ORM. Sometimes the best tool is the one you know. If your current application doesn't have a concise model layer, switching to ORM is going to require a lot of work. You could of course use hibernate and just use strait sql queries, but what's the point if you are not going to model your data.
Hopefully, all your persistence concerns are in one DAO layer, with lots of integration tests, so you can quickly identify what breaks when you switch RDBMS. If you don't have integration tests that focus on persistence, then now is the time to start writing them.