Can i depend on NHibernate 3.0 built-in Linq provider to perform complex queries contain aggregate functions such as Max and Min and contains string operations such as Contains, StartsWith, or EndsWith ??
The noticeable problems I found is:
.OfType() method is not implemented that can be a problem with inheritance hierarchies.
Left joins are not supported
Non-trivial group by operations do not work (even something as simple as sorting by group count).
Fetch() must be the last method in the query which can make paging with associated collections difficult.
However, it is definitely an improvement from the NHContrib provider.
The operations you listed are supported just fine in the usual scenarios.
There has been much debate on the nhusers list as there are quite a few issues still outstanding.
I would look on the nhusers group and
read some of the posts and make your
own mind up. See here for posts.
Personally I have found that queryover does all that I need so I for one would wait until the Linq provider becomes more stable over time.
I would recommned in joining the nhusers group to get a better feel.
The LINQ provider is far more stable and advanced than the one written by Ayende. (not dising what he wrote it was because of what he wrote that i picked up NH again)
I think the only issue I've come across with NH Query is composite types. You can do them in EF/L2S, and NH3 seems to generate the correct sql but fails to get to executing it.
Personally I like QueryOver, it reads better to me.
Related
I have many time scenarios that I only want to access only one/two/ or some no of columns and we are using hibernate so I want to know which is better for performance either
1) by fetching findById method of hibernate, which is very convenient for me because I have to just call it, but I think it will be not good in performance because it will fetch all column rather I require only some.
2) Or by creating my query each time that is tedious but it will be better in performance
So I want suggestion regarding what should I use?
To answer more specifically, it would be helpful if you included a code snippet. In general though, findById is a convenience method that will result in a query very similar to what you would write yourself. So writing the query yourself and returning only the columns you need (constructor expressions are useful) would be better in terms of performance. The question I would ask is, is that improved performance worth the more complicated code? You can always optimize your queries later.
It entirely depends on the entity which is being loaded. If the entity is one, with lots of relationships, and all you need is a couple of fields in the root entity, it is definitely worth writing your own query as Hibernate generates queries with JOINs to load the entity which can be very expensive. The other thing to consider here is that, you can always handle the fields that are being loaded using LAZY or EAGER loading but these settings are static and will be applied permanently to your entity.
On the other hand if the entity doesn't have many relationships, I believe the most expensive part is the conversation time between DB and your application, thus loading a number of extra fields can be ignored.
In a JPA project I need to display a table whose data comes from 5 related entities.
Without JPA I could write a sql query which joins the 5 database tables together and filters according to some criteria.
Suppose that the fields involved in the filtering criteria are only those of the first entity.
Using JPA I can load filtered instances of the first entity and navigate through the properties till the final entity.
My concern is that way the number of queries to the database can explode if I cannot use or do a mistake with the fecttype=eager annotation.
Which is the best approach in such cases ?
I would like to have a strict control over the sql queries that will be executed, so I can optimize them, but if I write the sql query with the joins by hand do I have to use the 'old' resultset to retrive the data ?
You can use JPA's built-in query language, the JPQL, can't you? (It does have a JOIN operator for sure.) Be aware though that this is not standard SQL, only something similar, so read the JPQL docs thoroughly. Yes, this is still plain text queries embedded in Java code, which is a shame, but hey, that's how far Java can go supporting the development process.
The main advantage here is that you get entity objects as the result of your queries - although you still need to cast them from Object. You can also use the objects (records) and their member variables (attributes) directly in the query string, so this is a step up from good old JDBC.
Alternatively you could also choose the Criteria API, but frankly, my experiences were not very good with it. The syntax is quite horrible and you basically end up building the low-level query yourself. This is clearly Java at its worst... but at least Strings containing queries can be eliminated from the code. I'm not sure it's worth it though.
Check this page for more information and examples:
http://download.oracle.com/javaee/6/tutorial/doc/gjise.html
While developing with Fluent nHibernate, I notice that on relationships I can specify a Fetch property, with possible options of Select(), Join(), and Subselect().
I did some searches for these and yielded very little information. I did find them in the nHibernate documentation and the fluent nHibernate documentation, but it does little other than give their signatures, which doesn't help me too much.
I was wondering if there is any real explanation for what these are, and what they really do. I've been rather perplexed myself. From my own evaluation they seem to change the way that referenced entities are pulled into the object graph, but I've yet to entirely discern how they change it, and which one is optimal for what situation...
I did find this blog post (http://www.mkyong.com/hibernate/hibernate-fetching-strategies-examples/) that has a little bit of detail but I'm still pretty perplexed about the entire situation. I've also seen other examples that state using Select() is more optimal, but the reasoning behind it. Additionally I found a post at (http://community.jboss.org/wiki/AShortPrimerOnFetchingStrategies) that is geared towards the original Java Hibernate platform, but I presume the concept is the same. In this one, my theory seems to be blown a bit as it focuses more on the lazy loading aspect of what they do, but I've still not seen any really flat examples.
Join fetching - NHibernate retrieves the associated instance or collection in the same SELECT, using an OUTER JOIN.
Select fetching - a second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.
Subselect fetching - a second SELECT is used to retrieve the associated collections for all entities retrieved in a previous query or fetch. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.
Check out the fetching strategy document # The Nhibernate Documentation
I'm not really familiar with nHibernate (I work with Hibernate and Java), but based on analogy, this enables you to specify association/collection property which you want to load eagerly, with the given entity. This is useful when you don't have full control over (n)Hibernate sessions (i.e if some other framework like Spring in Java is taking care of sessions/transactions).
So your assumption is basically correct.
Select, Join, and Subselect are the ways to obtain the related property, and determine what kind of query will be performed in database. Which one is optimal, really depends on the situation you have.
Hope this helps a little,
Cheers.
My gut tells me that advanced NHibernate users would be against it and I have been looking for actual analysis on this and have found nothing, I'd like for the answer to address these questions:
What are the pros/cons of using it?
Are there any performance implications, both good or bad (e.g. use it to call stored procedures?)
In which scenarios should we use/avoid it?
Who should use/avoid it?
basically, what are the reasons to use/avoid it and why?
CreateSQLQuery exists for a reason, which is executing queries that are either:
Not supported
Hard to write
using any of the other methods.
Of course it's usually the last choice, because:
It's not object oriented (i.e. you're back to thinking of tables and columns instead of entities, properties and relationships)
It ties you to the physical model
It ties you to a specific RDBMS
It usually forces you to do more work in order to retrieve entities
It doesn't automatically support features like paging
But if you think it's needed for a particular query, go ahead. Make sure to learn all the other methods first (HQL, Linq, QueryOver, Criteria and Get) to avoid doing unnecessary work.
One of the main reasons to avoid SQL and use HQL is to avoid making the code base dependent on the RDBMS type (e.g. MySQL, Oracle). Another reason is that you have to make your code dependent on the table and column names rather than the entity names and properties.
If you are comparing raw SQL to using the NHibernate LINQ provider there are other compelling reasons to go for LINQ queries (when it works), such as type safety and being able to use VS reference search to determine in what queries a certain table or column is referenced.
My opinion is that CreateSQLQuery() is a "last way out" option. It is there because there are things you cannot do with the other NHibernate APIs but it should be avoided since it more or less goes against the whole idea of using NHibernate in the first place.
I was wondering whether there are situation that's more advisable to use ESQL?
Generally, I find ESQL frustrating (specially with all the special cases where you need to fully qualify an entity type) & probably anything done using ESQL can be done through SQL or LINQ.
But I was wondering of situations where ESQL is a better fit for a solution or would have a competitive edge over using SQL or LINQ (either easier/faster to code, or better performance, etc.)
So, what's the compromise here? When is it better to use each one of the three approaches in querying over EF4?
I find that ESQL to be good for edge cases, for example:
Where it's just really hard to express something in LINQ.
For building very dynamic searches.
If you want to use a database specific function that is exposed by the provider you are using.
Also, if you know Entity SQL, you will be able to express QueryViews and Model-Defined Queries.
I came across these pretty similar questions (which didn't show up when I typed mine, earlier) on stack over flow, I guess they have deeper discussions (though T-SQL is not mentioned a lot, but it's kinda pretty obvious though):
Linq to Entities vs ESQL - Stack
Overflow
Entity framework entity sql vs linq
to entities
Note that the two questions are a bit "old" so you might validate some of data based on your current understanding of EF4
Just as what julie mentioned. Esql is required to write model defined functions which in return can be used through LINQ to Entities Queries.
Most cased you'll be using LINQ to Entities. One another case where you can't use LINQ TO Entities us when you want to build queries with store functions, either buit in or UDF. In this case esql is your only way in EF1 but in EF4 you can use its features to expose those functions to be used in LINQ.
About performance, esql is performing better. but you might prefer productivity using Linq over performance gain using esql.