Modeler vs. consistency of DataMap/Entity/Attribute/Relationship

From: Holger Hoffstätte (holge..izards.de)
Date: Sun Mar 02 2003 - 10:17:53 EST

  • Next message: Holger Hoffstätte: "Q: making 'bad' Constructors protected/private"

    Dear chili heads :-)

    I've been trying to fix various aspects of both Modeler and the underlying
    core, and have noticed that a lot of code in Modeler is concerned with
    keeping the DataMap/Entity/Atribute/Relationship network together. For
    example get(Obj/Db)EntitiesAsList constantly creates new Lists for no good
    reason (an immutable reference could do just as well), same for e.g.
    getAttributeMap, getAttributeList, getRelationshipList etc. So I tried to
    cache these locally instead of constantly recreating them.
    Maintaining/invalidating these caches needs to be done too, since e.g.
    getPrimaryKey() needs to be updated when e.g. an externally gotten
    DbAttribute has changed to be a PK (clicked in Modeler) etc., so I added
    attributeChanged() and relationshipChanged() to Attribute and
    Relationship, have these called from any setters in subclasses..et voilá:
    cache coherency and no more needless List creation. Works perfectly, both
    in Modeler and a commandline-fetch app.

    It then dawned on me: I've basically reinvented modeler.event.DB/ObjEvents
    - badly. :}
    Obviously it would be much better to move the non-display related events
    to the core package, no?

    This would make Modeler a lot smaller, easier to refactor (and it _does_
    need some serious cleaning; it is really confusing and hard to modify
    right now..sorry Andrus ;) and also give a nice way of dealing with
    dynamically added Relationships, Attributes etc. in the core framework -
    think about the "select count(*)" trick of adding a derived attribute
    dynamically. Any on-thy-fly reconfiguration would become a lot easier,
    because the network can start to maintain itself instead of having to be
    kept in order externally. Also would make a lot of repeated
    traversing/rebuilding of internal data structures unnecessary.

    Does this sound like a good idea? If so, any volunteers? :->

    Holger



    This archive was generated by hypermail 2.0.0 : Sun Mar 02 2003 - 10:21:01 EST