Java Reference
In-Depth Information
Using the Java Persistence Query Language
If you want to do anything more than find objects by their primary key, you'll need to
use Java Persistence Query Language ( JPQL ) :
public List<Food> getFoodsWhoseNameContains(String foodName,
int maxResults) {
String query = "SELECT f FROM FOOD f WHERE LIKE '%" +
foodName + "%' ORDER BY f.quantity DESC";
Query q = em.createQuery(query);
List<Food> list = q.getResultList();
return list;
public int getFoodCount() {
Query query = em.createQuery("SELECT COUNT(f) FROM FOOD f");
Number count = (Number) query.getSingleResult();
return count.intValue();
JPQL may bring back unpleasant (or pleasant) memories of SQL for some of you. In
terms of syntax, it's much like SQL , but avoids most vendor-compliance compatibility
issues. It breaks the object-oriented abstraction provided by JPA and makes it clear that
there is a database involved in all this.
One slight disadvantage of allowing JPA to create all your database tables for you in
memory is that the database will always be completely empty when you start the sys-
tem. This is fine for some applications, but it's not ideal for a food shop that's sup-
posed to have food. Use another Blueprint bean to initialize the database when the
system starts:
ref="inventory" />
If you're familiar with OSG i bundle activators, you'll recognize that this bean plays a
similar role. It's activated as soon as the bundle starts, rather than waiting to be looked
up or injected into another bean. The advantage over a normal bundle activator is it
can be injected with any other Blueprint reference.
Another advantage of the InventoryPopulater over a bundle activator is that an
eager Blueprint bean isn't required to implement any special interface (see the
Search WWH ::

Custom Search