how add wildcard query when using hibernate search. I am using Hibernate Search 3.1.1GA jar and unable to upgrade my jar to upper version. In upper version of hibernate we can use wildcard method using Query Builder.
I am stuck please help me out.
I assume you are referring to the Hibernate Search query DSL. Something like this:
Query luceneQuery = queryBuilder
.keyword()
.wildcard()
.onField("foo")
.matching("bar*")
.createQuery();
This DSL is indeed not part Search 3.1.1 and was added later. In this version you need to build your queries by using native Lucene queries. Really all the Search DSL does is under the hood building these native queries for you. In your case you want to look at org.apache.lucene.search.WildcardQuery or you could use the org.apache.lucene.queryParser.QueryParser to use the Lucene query syntax which also allows wildcards.
How can I use the tools to generate DAOs?
In fact, instead of passing through the hbm files, I need to configure hibernate tools to generate the DAO and the annotations.
See Hibernate Tools - DAO generation and How generate DAO with Hibernate Tools in Eclipse?
First let me assume DAO as POJO/Entity beans. Basically you can accomplish your task either through forward or reverse engineering. In case of forward engineering, probably you can look into AndroMDA tool. In case If u wish to accomplish it through reverse engineering Click here ..
Hope this will be helpful.
Welcome. You got to write all your data access logic by your hand (if I’m not wrong). Hiberante let you interact with database in three ways.
Native SQL which is nothing but DDL/plain SQL query. This can be used very rarely in hibernate projects even though this is faster than below mentioned options. Reason is simple “One of the key advantage of hibernate or any other popular ORM framework over JDBC Is you can get rid of database specific queries from your application code!”
HQL stands for hibernate query language which is proprietary query language of hibernate. This looks similar to native SQL queries but the key difference is object/class name will be used instead of table name and public variable names will be used instead of column names. This is more Object oriented approach. Some interesting things will be happening in background and check if you are keen!
Criteria API is a more object oriented and elegant alternative to Hibernate Query Language (HQL). It’s always a good solution to an application which has many optional search criteria.
You can find lots of examples on internet. Please post your specific requirements for further clarification on your problem.
Cheers!
Is there a way to get the columns in the order they are
declared in the Java class, or to specify the order in some other way?
I'm using the mapping tool ant task to generate the DDL for my classes in a sql file.
No, each implementation of JPA is free to arrange the columns in the generated DDL in the order it sees fit, and in general the programmer has no control over this - for example: Hibernate uses alphabetical order, but DataNucleus allows the specification of a column position thanks to a non-standard annotation. Sadly, OpenJPA doesn't provide a mechanism for specifying column ordering.
I had a similar problem a while ago, the data base guidelines of my client mandated a certain ordering in the columns and my JPA provider produced a different order. The solution? we wrote a text-processing Java program that, given the generated DDL as input, reordered the columns in the code so it satisfied the guidelines and produced as output a new file with the modified DDL; the program was run from an Ant task. Not pretty, but from a practical standpoint it was the best solution we could muster.
Request: /api/person?$filter Name eq 'John' with server backed up method that
return repo.GetAll().Select(o => Mapper.Map<>PersonDTO>(o));
Only the $filter requests error out with "Where with predicate after a project is not supported" but $top / $skip / $orderby work fine. My guess is, Mongo C# has a bug while generating the query & projects before applying the filter. Instead it should apply filter first and then project. I am using OData 5.2.0-rc1 and Mongo C# driver is 1.7.
Any inputs are much appreciated. Thanks...
That is a limitation in the current implementation of Linq. We are working to correct that with this ticket: https://jira.mongodb.org/browse/CSHARP-601.
However, I'd encourage you to figure out what you are actually attempting to do. Projecting prior to a filter could mean you are filtering on computed expressions, such as adding 2 columns together. MongoDB queries do not support this type of behavior, which is why this is currently disallowed by our linq provider. Aggregation framework allows this to a point, but there are a different set of limitations imposed by the Aggregation framework.
In your particular case, what you are wanting us to do is impossible. You are asking us to know how to create a MongoDB query based on an AutoMapper generated object. This simply impossible unless we (at runtime) read the AutoMapper mapping and apply it to our internal class models.
When using the Entity Framework, does ESQL perform better than Linq to Entities?
I'd prefer to use Linq to Entities (mainly because of the strong-type checking), but some of my other team members are citing performance as a reason to use ESQL. I would like to get a full idea of the pro's/con's of using either method.
The most obvious differences are:
Linq to Entities is strongly typed code including nice query comprehension syntax. The fact that the “from” comes before the “select” allows IntelliSense to help you.
Entity SQL uses traditional string based queries with a more familiar SQL like syntax where the SELECT statement comes before the FROM. Because eSQL is string based, dynamic queries may be composed in a traditional way at run time using string manipulation.
The less obvious key difference is:
Linq to Entities allows you to change the shape or "project" the results of your query into any shape you require with the “select new{... }” syntax. Anonymous types, new to C# 3.0, has allowed this.
Projection is not possible using Entity SQL as you must always return an ObjectQuery<T>. In some scenarios it is possible use ObjectQuery<object> however you must work around the fact that .Select always returns ObjectQuery<DbDataRecord>. See code below...
ObjectQuery<DbDataRecord> query = DynamicQuery(context,
"Products",
"it.ProductName = 'Chai'",
"it.ProductName, it.QuantityPerUnit");
public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
return result;
}
There are other more subtle differences described by one of the team members in detail here and here.
ESQL can also generate some particularly vicious sql. I had to track a problem with such a query that was using inherited classes and I found out that my pidly-little ESQL of 4 lines got translated in a 100000 characters monster SQL statetement.
Did the same thing with Linq and the compiled code was much more managable, let's say 20 lines of SQL.
Plus, what other people mentioned, Linq is strongly type, although very annoying to debug without the edit and continue feature.
AD
Entity-SQL (eSQL) allows you to do things such as dynamic queries more easily than LINQ to Entities. However, if you don't have a scenario that requires eSQL, I would be hesitant to rely on it over LINQ because it will be much harder to maintain (e.g. no more compile-time checking, etc).
I believe LINQ allows you to precompile your queries as well, which might give you better performance. Rico Mariani blogged about LINQ performance a while back and discusses compiled queries.
nice graph showing performance comparisons here:
Entity Framework Performance Explored
not much difference seen between ESQL and Entities
but overall differences significant in using Entities over direct Queries
Entity Framework uses two layers of object mapping (compared to a single layer in LINQ to SQL), and the additional mapping has performance costs. At least in EF version 1, application designers should choose Entity Framework only if the modeling and ORM mapping capabilities can justify that cost.
The more code you can cover with compile time checking for me is something that I'd place a higher premium on than performance. Having said that at this stage I'd probably lean towards ESQL not just because of the performance, but it's also (at present) a lot more flexible in what it can do. There's nothing worse than using a technology stack that doesn't have a feature you really really need.
The entity framework doesn't support things like custom properties, custom queries (for when you need to really tune performance) and does not function the same as linq-to-sql (i.e. there are features that simply don't work in the entity framework).
My personal impression of the Entity Framework is that there is a lot of potential, but it's probably a bit to "rigid" in it's implementation to use in a production environment in its current state.
For direct queries I'm using linq to entities, for dynamic queries I'm using ESQL. Maybe the answer isn't either/or, but and/also.