empire-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: Example of using Options?
Date Fri, 27 Sep 2013 09:24:38 GMT
 

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:doebele@esteam.de] 
to: user@empire-db.apache.org
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:timcolson@yahoo.com] 
to: user@empire-db.apache.org
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 <francisdb@gmail.com> 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 <timcolson@yahoo.com> 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

 


Mime
View raw message