Hi Jeremy,
If I remember correctly, Dan has examples for overriding the "Finder"
methods in the ToDo demo / artefact that use JDO search classes to
build queries.
In fact:
In the "ToDoItemsJdo" class (which extends an
AbstractFactoryAndRepository):
// {{ notYetComplete (action)
@Override
protected List<ToDoItem> doNotYetComplete() {
return allMatches(
new QueryDefault<ToDoItem>(ToDoItem.class,
"todo_notYetComplete",
"ownedBy", currentUserName()));
}
// }}
This appears in an old copy of the repo I have in the wicket JDO
quickstart project.
So while you can't use "FindByPattern", JDO has implemented a
useful alternative.
Regards,
Kevin
On 27 Aug 2013 at 14:37, Jeremy Gurr wrote:
> I'm playing around with the cucumber support tools in isis (a testing
> framework for behavior driven development, for those who don't know), and
> have created a test that basically looks like this:
>
> <snip>
>
> It's very convenient that cucumber instantiates my ServiceClass model object
> and automatically plugs in fields according to the feature spec column
> header. This enables me to add new fields simply by adding a column in the
> spec, and adding the corresponding column in my model object. It skips the
> extra hassle of having to update the glue code as well as service methods to
> construct the object.
>
> The "exists" method contains this code:
>
> public boolean exists(ServiceClass serviceClass) {
> final QueryFindByPattern<ServiceClass> query = new
> QueryFindByPattern<ServiceClass>(ServiceClass.class, serviceClass);
> final ServiceClass firstMatch = firstMatch(query);
>
> return firstMatch != null;
> }
>
> I'm just trying to verify that an object exists with fields matching the
> incoming object, some fields of which may be null, meaning that they can be
> any value. The QueryFindByPattern class seemed to be a perfect fit since I'm
> passing around ServiceClass instances anyway. However, running it executes
> code that is not yet implemented:
>
> <snip>
