Re: get**AsList/Map again ;-)

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Mar 13 2003 - 13:02:34 EST

  • Next message: Holger Hoffstätte: "Re: get**AsList/Map again ;-)"

    So there are a few issues here:

    (1) stripping "AsList" suffix. (+1) I don't like it myself. Let's do it.
    (2) changing List to Collection. (-1) Lists are easier to use in the GUI.
    One thing Cayenne does already is alphabetic ordering of entities and
    such.
    (3) returning immutable collections. (+0) I kind of like it, but we need
    to dig into all the consequences (especially in the modeler). I know you
    are already checking into that...
    (4) Schedule: There are a few things that need to be implemented before Beta:

     - stored procedure support
     - Andriy's imheritance work
     - Arndt's inheritance patches (we need to make a schedule decision about
    those - anyone feels like integrating them now?)

    Beta will take at least a few more weeks (I will be on vacation in Europe
    early April, I hope we can release till then, but I don't have the
    confidence). So if you feel like doing naming refactoring, there is this
    time window.

    Once we are in Beta I would suggest to freeze API and only fix bugs (with
    Modeler being a possible exception). This is the whole point of Beta.

    Now comments on individual items:

    > DataContext.getDataMapsAsList:
    > - could be renamed to getDataMaps (original name actually)
    > - just returns getDataMapsAsList from its parent (DataDomain, see next
    > item); IMHO a good idea to change both to return an immutable
    > write-through Collection reference. This better decouples the
    > QueryEngine method from the internal implementation (no implementation
    > details in interfaces!)

    I am not sure I am following this. I don't see a problem with DataContext
    relying on parent's implementation. Changing DataDomain to return an
    immutable list is totally OK. Renaming getDataMapsAsList -> getDataMaps in
    the interface (and all implementations) is OK.

    > DataMap:
    > - rename to getDb/ObjEntities
    > - return immutable read-through Collection
    > - remove getDbEntityMap (not used elsewhere)
    > -or-
    > - remove *List methods completely
    > - rename getDb/ObjEntityMap to getDb/ObjEntities
    > - return immutable read-through Map

    I'd prefer keep the (renamed) list method, and keep the Map methods
    (returning immutable maps I guess).

    > Entity:
    > - get(Attribute|Relationship)(Map|List): either/or, just like with
    > DataMap
    >
    > DataContext:
    > - instead of calling clearFlattenedUpdateQueries from ContextCommit make
    > DC clean up itself after commit; make method private or remove
    > completely

    +1. If ContextCommit can only rely on public API in DataContext, this
    would be great.

    > ObjRelationship:
    > - rename getDbRelationshipList to getDbRelationships
    > - return immutable List
    > - cache reverseRelationship
    >
    > DbRelationship:
    > - cache reverseRelationship

    We can only cache stuff when we implement reliable update mechanism via
    notifications.

    Andrus



    This archive was generated by hypermail 2.0.0 : Thu Mar 13 2003 - 13:02:35 EST