Spring Data JPA - Limit query size

This one is very informative and short:

If you are using Spring Data JPA, you are probably familiar with the technique of query creation out of methods names.

Following that mechanism, there is no explicit way to use the LIMIT keyword in the query name,
However, there is a simple way to use the SQL LIMIT with these queries.
The implicit way to limit the query result size is to utilize the pagination mechanism.
 
Simply provide and extra paging object with the objects number you need to limit.


Below is a simplified example of how the repository interface should be used:

public interface EntityRepository extends CrudRepository, JpaSpecificationExecutor {

 List findByEntityMemberNameLike(String query, Pageable pageable);//Pageable will limit the query result

}

Below is a simplified example of how the usage of such query could be:

@Autowired
EntityRepository entityRepository;

...

int queryLimit = 10;
List queryResults = entityRepository.findByEntityMemberNameLike(queryString, new PageRequest(0, queryLimit));

LESS is more?

Recently I've been exposed to LESS which is a UI framework.
In a nutshell, this framework extends the standard CSS in a way that insert programming flavor into it, such as inheritance, variables, functions and build.
(By the way - this is not the only framework with such concept)


Using this framework has some pros and cons which I would like to highlight.
Pros:

• Enable css reuse via inheritance, variables and more.
• Build *one* css for the final html to use.

Cons:

• Introduce another development language, which requires strong CSS knowledge (if you use it well, otherwise, no point to use it)
• End-to-end developers (UI to server) might need another domain to maser
• Coupling your project with another framework. Disconnecting from less is not simple
• Produced css are not ideal for development phase and debug
• CSS changes can be done only via this framework/language

At first review this LESS technique sounds like a css simplification magic, however at the end we stopped using it since its cost/benefit was low.

Please let me specify my claims.
The main disadvantage of this framework, IMHO, is that it makes your project too couples with it.
While the generated CSS is ideal for production, in development environment, it's very hard to work with.
In a typical project where several UI frameworks (e.g. jquery) are involved - imagine how long the one output css file will be.
Moreover, not only that it would be very hard to work on the CSS output directly, it would be very hard in the future to separate it to file per framework since LESS does not support it.

Another disadvantage is that in order to use this framework properly, the developer need to learn another language and expertise in a domain which is not necessary the developer strong side.

This tool is mainly used by UI side people, so knowing that tool is like Java developer to know Spring framework, however, this does not work the other way around - for Java developers such tool added complexity. It is one thing to know JS or modify slightly css, and another thing to have experience in CSS inheritance and advanced techniques.

I think it applies for LESS developers as well. How many UI developers do you know who master Spring or Hibernate...

Anyway I hope my experience would help other to estimate whether to use such framework or not.

Eclipse metamodel generation (JPA 2.0) issues

Update:
Please see updated post in that manner which simplifies the process a bit better.

Static Metamodel classes are uses for type safe queries in JPA2.0 standard.

There are few ways to create these classes:
1. Define the IDE (e.g. eclipse) to generate the files automatically (like the IDE automatic build which generates the class files on each Java file change).
2. Define maven to generate the files. The generation will be done when running the maven script.

 I would recommend to avoid the generation via the Eclipse IDE, since I've noticed that the generated static meta model are inaccurate (e.g. some members were missing).

 I'm not sure what the reason is since the missing member has no special attribute that differentiate it form the other class members that are generated, however, the fact is that it is constantly not generated.

Static meta model files generation via maven overcome this issue.


Good luck !

Too L@zy for Debug

If you use JPA in your application and have @Lazy fetching on your Entities properties, please note that debugging might be impossible.

for example:

@Entity
public class Order[
@OneToMany(fetch=FetchType.LAZY,mappedBy = "order")
Set items;
//...
}

I encounter the issue with Spring IDE (STS 2.9), Spring 3.1 and JUnit 4.
When running a JUnit test  against the Service layer which needed to read lazy properties - same line of code (the invocation of a Lazy property) failed on Debug (exception) however succeeded on Run mode.

The problematic line is something like that:

Order order = getOrderById(orderId);
order.getItems(); // Exception on debug

Black magic indeed.

Hope this save time to someone..

When developers responsible to UX

While browsing in a mobile eCommerce site, I found something I haven't seen before and which I think quite amusing.
I guess that how web sites would have been look if developers would be responsible for UI.. :-)
 

Pay attention to the number the counting start with. :-)

Know your audience

Recently I've look into this blog statistics and saw the usage by browser type.
I was surprised to see that IE has less than 9% share.

Yes ! less than 9 percent.

The second surprise hit me when I looked in the usage by operating system.
Here MS has 53%.

Few years ago, when Firefox just arrived, the trend of MS losing its power just began, however, MS was still the dominant player.

That made me wonder if we are already in a time where MS empire lost its power or is it just a mirage..?

After a quick search I've noticed there are significant differences between sites.
For instance, in w3schools.com, another developer oriented site IE was ~18% . I guess we could find the opposite statistics on mainstream news oriented sites.

It appears that each site has it's unique characteristics based on its audience.

So I guess now it is the right time to put the famous quote "There are Lies, damned lies, and statistics", so whenever there is an opinion about the current market share in the browser domain, always try to find the origin and source and try to see if there is reference about the audience that research is based on. It might make the whole difference.

I know it sounds obvious, however, as developers, when we think about new feature to develop, we tend to think in the terms, concepts and examples we borrow from our daily activities, such as the browser type, standards to use, etc..  and assume our clients will catch that gap sometime..

So my advice is that next time just stop a bit and ask yourself who your audience is?

Try to have some statistics on them, so you'll have facts and not speculations and your opinion will be less biased.
(do it at least till IE will indeed be 9% share in the mainstream as well.. :- )

Spring 3.1 Release Train is complete

On March 14, 2012 SpringSource and VMware announced (and here) that the Spring 3.1 Release Train is complete.

The following is now fully support Spring 3.1 (with some changes in bullets)

• Spring Integration 
• Spring Security 
• Introduce session "validation" strategy instead of having invalid session check directly in SessionManagmentFilter  
• Remove internal evaluation of JSP EL
• Support HttpOnly Flag for Cookies in Servlet 3.0 Environments
• Allow HttpSessionSecurityContextRepository to have different session key for different instances
• Spring Batch 
• Spring Data 
• Support for locking
• Support for @IdClass in entities
• Support for LessThanEqual and GreaterThanEquals, True/False keywords in query methods
• Added CDI integration for repositories
• Improved parameter binding for derived queries for null values
• Spring Mobile 
• iPad is now recognized as a mobile device
• Split out Spring Mobile's WURFL integration into a separate project
• Added DeviceUtils and SitePreferenceUtils for convenient lookup of the 'currentDevice' and 'currentSitePreference', respectively.
• Simplified packaging by collapsing the device.mvc and device.lite sub-packages into the device root package
• Spring for Android  
• Android Auth - support for Spring Social & spring Security
• Updated RestTemplate to be compatible with Spring Framework 3.1
• Added support for Basic Authentication
• defaulting to standard J2SE facilities (HttpURLConnection) in Gingerbread and newer, as recommended by Google

Wish you an easy upgrading!