I have had another look at our basic example (empire-db-example-basic) and I
must admit that the definition of the gender options has not been solved well.
Thus I have added an enum for the available genders:
public class SampleDB extends DBDatabase
{
...
public enum Gender
{
M, // Male
F; // Female
}
public static class Employees extends DBTable
{
...
public Employees(DBDatabase db)
{
...
// Create Options for GENDER column
Options genders = new Options();
genders.set(Gender.M, "Male");
genders.set(Gender.F, "Female");
GENDER.setOptions(genders);
}
}
The corresponding client code now looks like this:
cmd.where(db.EMPLOYEES.GENDER.is(Gender.M));
Regards,
Rainer
from: Rainer Döbele [mailto:[email protected]]
to: [email protected]
re: re: Example of using Options?
Hello Tim,
at the moment Options of a column are optional metadata intended for a GUI to
provide a selection of values (i.e. a dropdown).
In my projects I define the keys as constants or even enums and I use the
message key as a value:
e.g.
public static class Genders
{
public static final String MALE = "M";
public static final String FEMALE = "F";
}
public void initOptions()
{
Options genders = new Options();
// value is translation key that is resolved at runtime
genders.set(Genders.MALE, "genderOptions."+Genders.MALE);
genders.set(Genders.FEMALE, "genderOptions."+Genders.FEMALE);
EMPLOYEES.GENDER.setOptions(genders);
}
At the moment there is no enforcement of using one of the option values.
However for records it can easily be added by subclassing DBRecord like this:
public class MyRecord extends DBRecord {
@Override
public Object validateValue(Column column, Object value)
{
Options options = column.getOptions();
if (options!=null)
{
if (!options.contains(value))
throw new FieldIllegalValueException(column,
String.valueOf(value));
}
return super.validateValue(column, value);
}
}
In this case you will always need to use your record class instead of DBRecord,
but I'd recommend to do that anyway as you will probably find other behavior
you want to adjust.
We will even consider adding this functionality in DBRecord (or the
Column.validate()) in a future release.
However as far as DBCommand (including setting constraints) is concerned, this
is much more low level and there will definitely not be a check on that level.
It is not the aim of Empire-db to enforce rules and constraints, only few
validations - mostly regarding necessary type conversions - are performed by
Empire-db itself.
Rather Empire-db provides access to meta-information that a client can use to
do whatever validation checks are necessary.
After all, having a constraint like cmd.where(EMP.GENDER.is("X") ) may not make
sense, but it will still result in a valid SQL statement even though it
probably will lead to an empty result.
I hope this answers your question.
Regards,
Rainer
from: Tim Colson [mailto:[email protected]]
to: [email protected]
re: Re: Example of using Options?
I'm looking at the Tutorial example, where the GENDER column is assigned
options, and thinking about how to leverage those values:
// Create Options for GENDER column
Options genders = new Options();
genders.set( "M", "Male");
genders.set("F", "Female");
GENDER.setOptions(genders);
For example, when updating a record, seems like there is an opportunity to make
sure the string is one of the valid options.
rec.setValue(db.EMPLOYEES.GENDER, "M");
And seems like a useful list to check when writing select constraints.
cmd.where(EMP.GENDER.is <http://emp.gender.is/> ("M") );
Might look something like this:
cmd.where(EMP.GENDER.is <http://emp.gender.is/> (GENDER.OPTIONS.M) );
As I look at the Javadoc & source, seems this isn't how things are done, need
to use the strings, so no compile time check, but I could do a run-time
validation of an incoming value (g = "F") to verify g is one of the valid
Options.
-Tim
On Sep 26, 2013, at 2:25 PM, Francis De Brabandere <[email protected]> wrote:
Could you post some more code as I'm not really following on what you
are trying to accomplish...
On 20 September 2013 20:35, Tim Colson <[email protected]> wrote:
Options seem like a really cool thing to use, especially for a field that is a
"STATUS" that represents stages of workflow.
I'm wondering how we would leverage Options in a Model object so that when for
example we want to findAllObjectsByStatus(listOfStatus) that it ensures at
compile time that we are looking only for valid status types?
-Tim
