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

From: Craig Miskell (cmiskel..lbatross.co.nz)
Date: Sun Mar 02 2003 - 13:44:36 EST

  • Next message: Craig Miskell: "Re: Q: making 'bad' Constructors protected/private"

    I wouldn't say I volunteer just yet, but I'd certainly like to see it
    happen! :-) (Like a lot of things I guess... easier to say "go for it"
    then "I'll go do it").

    Just to add though, it would give a definite one-up on EOF. At the
    moment I believe you can do such things, but it's not documented, and
    there's no real guarantee it'll work and won't break other stuff

    Craig
    On Mon, 2003-03-03 at 04:17, Holger Hoffstätte wrote:
    >
    > 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 - 13:45:17 EST