Re: Type-safe qualifiers

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Dec 31 2009 - 04:44:05 EST

  • Next message: Andrus Adamchik: "Re: Type-safe qualifiers"

    On Dec 31, 2009, at 11:24 AM, Andrey Razumovsky wrote:

    > 1. Instead of:
    > Expression clause2 =
    > ExpressionFactory.matchExp(Artist.PAINTINGS_PROPERTY +
    > "." + Painting.NAME_PROPERTY, "Y");
    > I prefer using just
    > Expression clause2 =
    > ExpressionFactory.matchExp("paintings.paintingName",
    > "Y");
    > Yes, I don't like using constants, to me bottom example seems more
    > readable,
    > short and quicker to write (especially if there are a lot of items
    > in the
    > path). As far as I understood, this will not be allowed in new API (?)

    Looks like your schema doesn't change too often :-)

    Anyways, we can still allow that in the new API. And even preserve
    "declarative" type-safety:

    Expression clause2 = new Key<String>("paintings.paintingName").eq("Y");

    > 2. I wrote a library which automatically builds Cayenne expressions
    > from
    > values user specified in grid filter of Web (GWT) client - path is
    > coming
    > from client. With new API, shall I have something like
    > CayenneDataObject.getKey(String) method to obtain any key in uniform
    > way?
    > (even with that, I will have more work to do to convert path to new
    > API,
    > maybe we need some method like Key Cayenne.getNestedKey(Class clazz,
    > String
    > path)?

    See the example above (new Key<?>(...)). Capability-wise the new API
    will allow everything ExpressionFactory does.

    > 3. I have examples of intentionally not following type-safing for
    > expressions (these are real examples)
    >
    > a. EF.matchExp("artist", "200") - quick comparison of relation
    > object's id
    > b. EF.lessExp("date", "2010-01-01 10:00:00.000") - replacement of
    > date (or
    > int, double, whatever) with just string
    >
    > Will those be allowed somehow in new API?

    I guess there are two ways about it.

    1. new Key<Object>(..)
    2. Provide methods that do String to object conversions for common
    cases of dates and numbers, using explicit or implicit formatters E.g.

        new Key<Date>("dob").after("2010-01-01 10:00:00.000", "YYYY-mm-
    dd...");
        new Key<Integer>("age").eq("200");

    Among other things this will make some drivers (like PostgreSQL)
    happy, as they don't allow fuzzy types in PreparedStatement bind
    parameters.

    >
    > Happy New Year!!!

    Happy New Year to everybody :-)

    Andrus



    This archive was generated by hypermail 2.0.0 : Thu Dec 31 2009 - 04:44:41 EST