Re: AW: "map" properties?

From: Robert Zeigler (robert..uregumption.com)
Date: Tue Jan 16 2007 - 04:03:17 EST

  • Next message: Peter Schröder: "AW: AW: "map" properties?"

    I probably didn't explain myself very well, apologies. The values in the
    map are still cayenne objects... I just want a map of them, instead of a
    list of them. :)
    For instance...

    Given a users table, a user_preferences table, and a one-to-many
    relationship between users and user_preferences, you would wind up with
    a set of objects that look something like:

    _User.java:
      public List getUserPreferences() {...}
      public void addToUserPreferences(UserPreference pref) {...}

    _UserPreference.java
      public void setUser(User u){...}

    Now suppose I want to grab a user's preferred layout.
    I /could/ do (bleh... inefficient):

    public UserPreference getPreferredLayout() {
    for(UserPreference pref : this.getPreferences()) {
      if (pref.getName().equals("preferred_layout")) {
        return pref;
      }
    }
     //do some default behavior, like return a default preference for
    layout, or throw an exception, or whatever.
    }

    Or, I could do:
    public UserPreference getPreferredLayout() {
      SelectQuery query = new SelectQuery(UserPreference.class);
      Expression e =
    ExpressionFactory.matchExp(UserPreference.USER_PROPERTY,this);
      e =
    e.andExp(ExpressionFactory.matchExp(UserPreference.NAME_PROPERTY,"preferred_layout"));
      query.setQualifier(e);
      List ret = this.getDataContext().performQuery(query);
      if (ret.isEmpty()) {
        //default behavior
      } else {
         return (UserPreference) ret.get(0);
      }
    }

    which is ok... but gets tedious if you have many of these sorts of
    map-type properties...
    What I'd /like/ is for cayenne to provide this sort of behavior out of
    the box. Instead of modeling a to-many as a list, which is faulted on
    first access, have the relationship be a map. Just like the current
    List-based implementation, the map would be empty until a property (eg:
    size) is accessed; then cayenne would partially resolve the map: the
    object key and the objectid would be fetched. Cayenne would subsequently
    fault individual objects as they are accessed... basically, what happens
    now with the List-based implementation, but providing the convenience of
    being able to easily (for the developer :) access a particular object
    based on the (developer-defined) key property.

    In that scenario, my helper method would be:
    public UserPreference getPreferredLayout() {
      return getPreference("preferred_layout");
    }

    Granted, I could write wrapper/helper methods to stick the list into a
    map. But then I have to worry about holding onto references to stale
    objects, etc. It would be much nicer if cayenne could manage that sort
    of thing.

    Robert

    Peter Schröder wrote:
    > hi robert,
    >
    > what do you need a name for?
    > you get cayenne-objects from that relationship whom you can access via getters and setters?!
    >
    > -----Ursprüngliche Nachricht-----
    > Von: Robert Zeigler [mailto:robert..uregumption.com]
    > Gesendet: Dienstag, 16. Januar 2007 05:14
    > An: cayenne-use..ncubator.apache.org
    > Betreff: "map" properties?
    >
    > Currently (to the best of my knowledge), cayenne always represents a
    > to-many relationship as a java.util.List. However, I was thinking it
    > would be nifty if cayenne supported map-representations of to-many
    > relationships. For instance, you could model a relationship between
    > Users and UserPreferences as a map, and specify the "name" property of
    > the UserPreferences table as the map key. Does that make sense? Am I
    > the only one who thinks that would be incredibly useful? :) Is something
    > like this already planned for 3.0?
    > If other people would find it useful, then I'd be happy to submit a
    > feature request and also work up a patch.
    >
    > Robert
    >



    This archive was generated by hypermail 2.0.0 : Tue Jan 16 2007 - 04:04:10 EST