SetLockMode(LockMode.None) or connection.isolation ReadUncomitted does NOT append a NOLOCK to your queries. Ayende goes into the correct answer on his blog: If you’re using <sql-query> you can do the following: <sql-query name=”PeopleByName”> <return alias=”person” class=”Person”/> SELECT {person.*} FROM People {person} WITH(nolock) WHERE {person}.Name LIKE :name </sql-query> Note the WTIH(nolock) appended to the FROM clause.
LikeExpression’s constructors are all protected, so it’s not a viable option. Also, it has problems of its own. A colleague and I created a patch which works pretty well. The gist of the patch is that for the LikeExpression constructor which consumes a MatchMode, we escape the special characters. For the constructor which consumes a … Read more
given these requirements there would be no difference, the generated SQL is the same: for mappings: <?xml version=”1.0″ encoding=”utf-8″ ?> <hibernate-mapping xmlns=”urn:nhibernate-mapping-2.2″> <class name=”Project” table=”Project”> <id name=”Id” type=”Int32″ unsaved-value=”0″> <column name=”Id” sql-type=”int” not-null=”true” unique=”true”/> <generator class=”native” /> </id> <many-to-one name=”Job” column=”FK_JobId” cascade=”save-update” not-null=”true” /> </class> </hibernate-mapping> <?xml version=”1.0″ encoding=”utf-8″ ?> <hibernate-mapping xmlns=”urn:nhibernate-mapping-2.2″> <class name=”Job” table=”Job”> … Read more
think works Criteria criteria = getSession().createCriteria(clazz); Criterion rest1= Restrictions.and(Restrictions.eq(A, “X”), Restrictions.in(“B”, Arrays.asList(“X”,Y))); Criterion rest2= Restrictions.and(Restrictions.eq(A, “Y”), Restrictions.eq(B, “Z”)); criteria.add(Restrictions.or(rest1, rest2));
Why do you use Restrictions.like(…)? You should use Restrictions.eq(…). Note you can also use .le, .lt, .ge, .gt on date objects as comparison operators. LIKE operator is not appropriate for this case since LIKE is useful when you want to match results according to partial content of a column. Please see http://www.sql-tutorial.net/SQL-LIKE.asp for the reference. … Read more
SQL supports UNION, but JPA 2.0 JPQL does not. Most unions can be done in terms of joins, but some can not, and some are more difficult to express using joins. EclipseLink supports UNION.
You can achieve the desired result by requesting a list of distinct ids instead of a list of distinct hydrated objects. Simply add this to your criteria: criteria.setProjection(Projections.distinct(Projections.property(“id”))); Now you’ll get the correct number of results according to your row-based limiting. The reason this works is because the projection will perform the distinctness check as … Read more
The common short term is just “Row values”. Or “Row value comparison” for the operation you demonstrate. That feature has been in the SQL standard since SQL-92 (!). Postgres is currently the only major RDBMS that supports it in all aspects – especially also with optimal index support. In particular, the expression (col1, col2) < … Read more
This is indeed possible with criteria: DetachedCriteria ownerCriteria = DetachedCriteria.forClass(Owner.class); ownerCriteria.setProjection(Property.forName(“id”)); ownerCriteria.add(Restrictions.eq(“ownername”, “bob”)); Criteria criteria = getSession().createCriteria(Pet.class); criteria.add(Property.forName(“ownerId”).in(ownerCriteria)); Update: This actually performs a sub-query instead of a join but it allows you to use Criteria on two entities that do not have a hibernate relationship defined.
In JPQL the same is actually true in the spec. The JPA spec does not allow an alias to be given to a fetch join. The issue is that you can easily shoot yourself in the foot with this by restricting the context of the join fetch. It is safer to join twice. This is … Read more