In my Project iam about to use Hibernate but one create confusion is:
That I Read somewhere:
Hibernate has its own query language, i.e hibernate query language which is database independent
So if we change the database, then also our application will works as HQL is database independent
HQL contains database independent commands
Does it means that we dont have to write stored proceedure and views while using Hibernate in java?
Short answer: You dont have to write any query and/or stored procedure. (Also you can hibernate tell to create/update all required tables for you, during application start.)
Long answer: Hibernate can be used without any manual definition of a query. (Using the EntityManager, you can simple tell hibernate to get everything of user.class from the database.) However it does support HQL as well as SQL-Queries, also.
SQL Queries of course will stop to work, when you switch to another database later on. HQL will work for every Database, because hibernate is able to translate HQL Queries to any (of the supported) Database Languages.
But be aware: In my Opinion Hibernate is damn slow if you let hibernate do all the work. (Hibernate fires a LOT of single Select Queries, when loading entities with complex relations)
Related
We have an ongoing project in which we use querydsl-jpa to make the queries.
When we deploy a new version of the product, it auto-executes sql file scripts to update the tables before starting hibernate. This scripts are just sql strings manually crafted (and very error prone).
I would like to use querydsl-sql to write the migration scripts programmatically and once that's done, use querydsl-jpa for normal ORM querying.
So the question is, if anyone knows if they can live together in the same project? And if anyone has done that before?
Using Querydsl JPA and SQL in a project together is a very common use case. You can for example use the JPA API and Querydsl JPA for CRUD use cases and Querydsl SQL for queries.
Querydsl SQL doesn't support DDL scripts (CREATE, ALTER etc). So that part is not covered by Querydsl.
I have worked on projects that involved creation of schema by hand coding sql scripts. Then we have used hibernate to do DML related activites.
Now, I am starting a project that involves extensive database entities creation and I was wondering if it is a good idea to use Hibernate itself to generate the entities. In other words, is hibernate capable of handling all possible DDL related scenarios, especially the ones that are complex in nature. Or, is it advisable to hand code the DDL sql scripts and use Hibernate for DML related tasks.
Thanks for your inputs.
No, Hibernate isn't able to handle all possible situations (synonyms, tablespaces, and all sorts of various things can't be handled by Hibernate).
I would only consider using Hibernate (to handle the schema creation and updates) for a quick and dirty POC. Otherwise, SQL scripts or Liquibase are your friends. You'll need them once you have a database in production that you need to migrate anyway.
We use a lot of view model builders which pass HQL strings to the ActiveRecordMediator.Execute method to populate search objects for our views.
Doing refactoring occassionally breaks these 'magic' hql strings (without us knowing)
I was wondering if anyone has tried using nhibernate named queries to validate HQL in Castle Active Record?
Is there another way rather than writing integration tests (we use LINQ to Nhibernate for basic searchs but its not quite there yet for our complex queries)
Anyone have suggestions how to validate HQL against your domain?
ActiveRecord supports named queries through the HqlNamedQuery attribute, see this article. By defining queries this way you get NHibernate's named query validation.
Plain-vanilla NHibernate setup, eg, no fluent NHibernate, no HQL, nothing except domain objects and NHibernate mapping files. I load objects via:
_lightSabers = session.CreateCriteria(typeof(LightSaber)).List<LightSaber>();
I apply raw user input directly to one property on the "LightSaber" class:
myLightSaber.NameTag = "Raw malicious text from user";
I then save the LightSaber:
session.SaveOrUpdate(myLightSaber);
Everything I've seen says that yes, under this situation you are immune to SQL injection, because of the way NHibernate parameterizes and escapes the queries under the hood. However, I'm also a relative NHibernate beginner so I wanted to double-check.
Thanks!
Yes, you're almost immune to SQL injection when using NHibernate. It uses parameterized queries for all generated SQL statements on all platforms that support these.
You can, however, circumvent this by using custom SQL for insertions/updates, or by executing SQL with a variation of execute_sql of some sort, or SQL Queries without parameters.
You're safe as long as you don't plug user input directly into HQL or SQL: nothing else (of the functionality hibernate provides) will allow users to inject malicious code.
Just to echo others, if you let NHibernate generate your SQL you're safe, at least in theory.
However, you still need to be careful with stored procedures, triggers, and functions in the database particularly with dynamic SQL. Even though the client uses parametrized queries everywhere, injection may still possible.
We have been suggested to use NHibernate for our project. But the point is our application will only be retrieving the data from the database so are there any benefits of using NHibernate in this scenario?
One more thing, what is the query execution plan in NHIbernate does it support something like prepared statements or the so called pre complied statements.?
I agree to the answers above, but there is one more reason for using nhibernate: Your completely independend of the underlaying database system. You can switch from mysql to oracle and the only thing you have to do, is to change the settings. the access to the database stays exactly the same.
NHibernate is useful is you need to map data from a database table into a .NET class. Even if you're only doing select queries, it still might be useful if you need to pass the data objects to a client tier (web page, desktop app, etc.) for display. Working with plain objects can be easier than working with a DataSet or other ADO.NET data class in a presentation layer.
NHibernate does have the ability to parse/pre-compile queries if you put them in the mapping file.
The benefit for using NHibernate in a read only scenario is that you would not need to map the results of queries back to .net objects as the runtime would do this for you. Also, it provides a more object oriented query syntax (you can also use LINQ), and you can take advantage of lazy loading.
I don't believe NHibernate can use prepared statements unless you are having it call stored procedures.