Criteria objects

[Sudsy]

VisionSet wrote:

But I'm a little unhappy about this, a null primary key?

Is this abuse of the object? should I have a separate criteria class?

I'm after the simplest design that I do feel happy about.

It's a perfectly valid approach (and one I've used). When you pass
value-objects containing record data, using the same for search
criteria makes sense. Ignore those fields which have been set to
null and only search on the populated fields, even if they are
empty Strings. So you're not actually searching for a null primary
key in your example. You're indicating that you haven't specified
the key and to not use it as part of the selection.
I should mention that if the database generates the primary key
automatically then setting it to null in the constructor is
perfectly valid when creating a new record.

 

[VisionSet]

I think there is a valid approach to retrieving records based on a criteria
object that is of the same class as the object you are retrieving.

A Record object may be used as the criteria to find other Record objects.

If we have a method such as

Record[] find(Record record);

then the argument can have any of its fields as null
this would signify no filtering on that field.

A criteria object could be set up as so:

public Record(Integer key, String[] data);

new Record(null, new String {"Foo", "Bar", null, null, null, null, null})

I think Hibernate uses this approach.

But I'm a little unhappy about this, a null primary key?

Is this abuse of the object? should I have a separate criteria class?

I'm after the simplest design that I do feel happy about.

 

[VisionSet]

VisionSet wrote:


It's a perfectly valid approach (and one I've used). When you pass
value-objects containing record data, using the same for search
criteria makes sense. Ignore those fields which have been set to
null and only search on the populated fields, even if they are
empty Strings. So you're not actually searching for a null primary
key in your example. You're indicating that you haven't specified
the key and to not use it as part of the selection.
I should mention that if the database generates the primary key
automatically then setting it to null in the constructor is
perfectly valid when creating a new record.

Thanks for the reply

When I use objects returned from the database I don't really want to have to
check for nulls in the fields.
But if I also use the class for criteria objects then I'm going to have to,
despite the fact I know my database won't return null fields my Record
documentation is going to say that null elements are valid.

 

[Chris Uppal]

I think there is a valid approach to retrieving records based on a
criteria object that is of the same class as the object you are
retrieving. [...]
Is this abuse of the object? should I have a separate criteria class?

I'm after the simplest design that I do feel happy about.

Like Susdy, I think this is a valid approach (and one I've used before too).

If your sense of aesthetics, or the nature of the data, make it impossible to
indicate which of an object's attributes are part of the search template and
which are "wildcards", then you could use an auxiliary indication of which
fields to search on and which to ignore. (When I did this, I was working in C
and the attributes had a natural association with integers so it was very
simple just to use a bitmap as the "auxiliary indication", whether there is
anything as handy for you will depend on your application).

-- chris

 

[Fredrik Bertilsson]

Have a look at the Query object in http://butler.sourceforge.net.

A Query object uses different subclasses of Filter - like AndFilter,
OrFilter, EqualsFilter - to define the where clause in the select
statement. It can also making joins (Join class) with other tables.

/Fredrik

 

[John C. Bollinger]

I think there is a valid approach to retrieving records based on a criteria
object that is of the same class as the object you are retrieving.

A Record object may be used as the criteria to find other Record objects.

If we have a method such as

Record[] find(Record record);

then the argument can have any of its fields as null
this would signify no filtering on that field.

A criteria object could be set up as so:

public Record(Integer key, String[] data);

new Record(null, new String {"Foo", "Bar", null, null, null, null, null})

I think Hibernate uses this approach.

But I'm a little unhappy about this, a null primary key?

Is this abuse of the object? should I have a separate criteria class?

I think it's a bit iffy from an OO purism point of view, but that
doesn't mean it couldn't be made to work fine. If you need to be able
to match against every field and combination of fields then you do need
a criterion object containing at least as much information as a Record,
so there is surely some advantage to using the Record class also for
criteria.

I'm after the simplest design that I do feel happy about.

If you're unsatisfied with using the same class, then you could consider
using inheritance. The fields and accessor methods could be on a
superclass that does not restrict its field values, and Record could be
a subclass (that need not redefine any accessor methods). You can
stipulate that Record instances may not have null fields (whether or not
you enforce it in code), but that that doesn't necessarily apply to the
superclass. If you like symmetry then you can make the criterion class
be a sibling of Record; otherwise you can just use the superclass.


John Bollinger
(e-mail address removed)