FAQ
Nice start!

I wonder what we can do to scale it to large projects? E.g.:

http://people.apache.org/~aadamchik/class.png

Coincidentally the same issue was discussed on a WebObjects mailing
list today. It is not yet archived, and if I don't forget, I'll
forward the links once it is archived.

Andrus

On Dec 2, 2009, at 4:50 PM, Andrey Razumovsky (JIRA) wrote:


[ https://issues.apache.org/jira/browse/CAY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784856
#action_12784856 ]

Andrey Razumovsky commented on CAY-762:
---------------------------------------

First version is committed on 3.1 trunk and I welcome everyone to
try it.
JGraph 5.13.0.0 is used as graph implementation.

There are two types of diagrams - ER (for DbEntities) and Class (for
ObjEntities). They are avaliable through "Graph" tab of DataDomain
information panel.

What IS done:
* drawing of entities with attributes and relationships between
them, showing arity of rels, inheritance
* quick showing entities in left-hand tree (using right-click
context menu), as well as some basic operation shortcuts
* lazy loading of graphs - they are not created until requested
* layout of firstly opened graph with entities (played a bit with
jgraph layouts, still not sure this is the best one). Note that
opening a large project may result in a complex web of entities
* saving graphs info as <domain_name>.graph.xml (and restoring).
Note that this file will not be used in classic Cayenne runtime
* synchronizing in both sides with left-hand tree
* scaling
* saving models as images
* undo support

What IS NOT done:
* editing objects (e.g. entity names, attrs) in graph
* finding object on the graph from its info panel
* grouping by datamaps (in fact, I've found that standard JGraph
grouping doesn't look well on my models).

Please post your comments
ERDiagram for Object Entities in Cayenne Modeler
------------------------------------------------

Key: CAY-762
URL: https://issues.apache.org/jira/browse/CAY-762
Project: Cayenne
Issue Type: New Feature
Components: CayenneModeler GUI
Affects Versions: 3.0
Reporter: Ahmed Mohombe
Assignee: Andrey Razumovsky
Fix For: 3.1M1


Please add an ER Diagram to the Cayenne Modeler. This is the
feature that I miss the most from WebObjects.
For start it would be even enough to have an ER Diagram View (so
no interactive activities) - just display and layout of entities.
I think this would help allot and would increase the productivity
with CM - most people think visually.
I don't think that it would be complicated to implement, the most
complicated question to answer is what graph library is allowed to
use, due to the restrictive "license compatibility" of the Apache
license.
Thanks in advance,
Ahmed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Search Discussions

  • Andrey Razumovsky at Dec 3, 2009 at 1:40 pm
    Well, I played with standard JGraph layouts for some time, this is the best
    I found. Probably I will return to this research someday. But definitely we
    can create big graphs on bigger sheet, then it well be less confusing.
    On the other hand, if you create projects from the start, you can constanlly
    and sequentially organize the graph, so it will not be so messy.

    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    Nice start!

    I wonder what we can do to scale it to large projects? E.g.:

    http://people.apache.org/~aadamchik/class.png<http://people.apache.org/%7Eaadamchik/class.png>

    Coincidentally the same issue was discussed on a WebObjects mailing list
    today. It is not yet archived, and if I don't forget, I'll forward the links
    once it is archived.

    Andrus



    On Dec 2, 2009, at 4:50 PM, Andrey Razumovsky (JIRA) wrote:

    [
    https://issues.apache.org/jira/browse/CAY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784856#action_12784856
    ]

    Andrey Razumovsky commented on CAY-762:
    ---------------------------------------

    First version is committed on 3.1 trunk and I welcome everyone to try it.
    JGraph 5.13.0.0 is used as graph implementation.

    There are two types of diagrams - ER (for DbEntities) and Class (for
    ObjEntities). They are avaliable through "Graph" tab of DataDomain
    information panel.

    What IS done:
    * drawing of entities with attributes and relationships between them,
    showing arity of rels, inheritance
    * quick showing entities in left-hand tree (using right-click context
    menu), as well as some basic operation shortcuts
    * lazy loading of graphs - they are not created until requested
    * layout of firstly opened graph with entities (played a bit with jgraph
    layouts, still not sure this is the best one). Note that opening a large
    project may result in a complex web of entities
    * saving graphs info as <domain_name>.graph.xml (and restoring). Note that
    this file will not be used in classic Cayenne runtime
    * synchronizing in both sides with left-hand tree
    * scaling
    * saving models as images
    * undo support

    What IS NOT done:
    * editing objects (e.g. entity names, attrs) in graph
    * finding object on the graph from its info panel
    * grouping by datamaps (in fact, I've found that standard JGraph grouping
    doesn't look well on my models).

    Please post your comments

    ERDiagram for Object Entities in Cayenne Modeler
    ------------------------------------------------

    Key: CAY-762
    URL: https://issues.apache.org/jira/browse/CAY-762
    Project: Cayenne
    Issue Type: New Feature
    Components: CayenneModeler GUI
    Affects Versions: 3.0
    Reporter: Ahmed Mohombe
    Assignee: Andrey Razumovsky
    Fix For: 3.1M1


    Please add an ER Diagram to the Cayenne Modeler. This is the feature that
    I miss the most from WebObjects.
    For start it would be even enough to have an ER Diagram View (so no
    interactive activities) - just display and layout of entities.
    I think this would help allot and would increase the productivity with CM
    - most people think visually.
    I don't think that it would be complicated to implement, the most
    complicated question to answer is what graph library is allowed to use, due
    to the restrictive "license compatibility" of the Apache license.
    Thanks in advance,
    Ahmed.
    --
    This message is automatically generated by JIRA.
    -
    You can reply to this email to add a comment to the issue online.


    --
    Andrey
  • Andrus Adamchik at Dec 3, 2009 at 1:42 pm

    On Dec 3, 2009, at 3:39 PM, Andrey Razumovsky wrote:

    if you create projects from the start, you can constanlly
    and sequentially organize the graph
    Good point.
  • Andrey Razumovsky at Dec 3, 2009 at 1:50 pm
    The ultimate goal is to add most model operations (add/remove/edit
    entity/attribute/relationship...) to graph panel. Then everything takes its
    place and you can edit model and organize graph at the same time

    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 3:39 PM, Andrey Razumovsky wrote:

    if you create projects from the start, you can constanlly
    and sequentially organize the graph
    Good point.

    --
    Andrey
  • Andrus Adamchik at Dec 3, 2009 at 1:40 pm

    On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

    * saving graphs info as <domain_name>.graph.xml (and restoring).
    Note that this file will not be used in classic Cayenne runtime
    I think this can be tied to preferences and saved in ~/.cayenne/.
    Saving it in the project tree has SCM implications.
    * grouping by datamaps (in fact, I've found that standard JGraph
    grouping doesn't look well on my models).
    This (an maybe an ability to filter/group entities by some criteria)
    may be the answer to working with large schemas.

    Andrus
  • Andrey Razumovsky at Dec 3, 2009 at 1:48 pm
    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

    * saving graphs info as <domain_name>.graph.xml (and restoring). Note that
    this file will not be used in classic Cayenne runtime
    I think this can be tied to preferences and saved in ~/.cayenne/. Saving it
    in the project tree has SCM implications.
    I thought of that..
    Lets take your example. You've got an enormous project, so no layout can
    place entities without intersections. You spend half a day to organize it
    well.. Then what? How can other members of the team see your changes? It is
    even better when graph is in SCM - it is not a big file, and allows everyone
    to see it. Graph file is XML, so SVN should merge it correctly. The only
    thing you need is exclude it from packaged version of your project (if you
    want).

    At last resort you can add graph files to something like svn:ignore
  • Andrus Adamchik at Dec 3, 2009 at 2:03 pm
    I agree with the premise, but I had bad experience with other ORM
    tools years ago that would save the layout together with the project,
    and then a single unintended mouse move results in making the project
    "dirty" and creates an underlying SCM change. IMO that was a
    distraction and created constant commit noise.

    So essentially managing a pretty layout is a parallel task to the main
    task of creating a model, and I don't want it to become a distraction.
    So maybe we can make it a project property (persist-layout: true|false
    (default))? If true, it will store the XML together with the project,
    if false, it will store it in local preferences?

    Andrus

    On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:
    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

    * saving graphs info as <domain_name>.graph.xml (and restoring).
    Note that
    this file will not be used in classic Cayenne runtime
    I think this can be tied to preferences and saved in ~/.cayenne/.
    Saving it
    in the project tree has SCM implications.
    I thought of that..
    Lets take your example. You've got an enormous project, so no layout
    can
    place entities without intersections. You spend half a day to
    organize it
    well.. Then what? How can other members of the team see your
    changes? It is
    even better when graph is in SCM - it is not a big file, and allows
    everyone
    to see it. Graph file is XML, so SVN should merge it correctly. The
    only
    thing you need is exclude it from packaged version of your project
    (if you
    want).

    At last resort you can add graph files to something like svn:ignore
  • Mike Kienenberger at Dec 3, 2009 at 2:23 pm
    I agree with Andrey. It should be saved as part of the project. It
    doesn't make any sense to have a project-specific piece of information
    stored in preferences. If you copy your project to another machine,
    you lose the information. If you delete the project, the information
    remains in preferences even though the project is gone.

    You should mark it as ignored if you don't want to put it in your SCM
    or if the noise bothers you.

    On Thu, Dec 3, 2009 at 9:03 AM, Andrus Adamchik wrote:
    I agree with the premise, but I had bad experience with other ORM tools
    years ago that would save the layout together with the project, and then a
    single unintended mouse move results in making the project "dirty" and
    creates an underlying SCM change. IMO that was a distraction and created
    constant commit noise.

    So essentially managing a pretty layout is a parallel task to the main task
    of creating a model, and I don't want it to become a distraction. So maybe
    we can make it a project property (persist-layout: true|false (default))? If
    true, it will store the XML together with the project, if false, it will
    store it in local preferences?

    Andrus

    On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:

    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

    * saving graphs info as <domain_name>.graph.xml (and restoring). Note
    that
    this file will not be used in classic Cayenne runtime
    I think this can be tied to preferences and saved in ~/.cayenne/. Saving
    it
    in the project tree has SCM implications.
    I thought of that..
    Lets take your example. You've got an enormous project, so no layout can
    place entities without intersections. You spend half a day to organize it
    well.. Then what? How can other members of the team see your changes? It
    is
    even better when graph is in SCM - it is not a big file, and allows
    everyone
    to see it. Graph file is XML, so SVN should merge it correctly. The only
    thing you need is exclude it from packaged version of your project (if you
    want).

    At last resort you can add graph files to something like svn:ignore
  • Andrey Razumovsky at Dec 3, 2009 at 2:31 pm
    We can have some check box "save graph changes" for every graph. by default
    it is false, and turns on if there were major changes (e.g. entity added) or
    checked manually. Minor changes (entity moved, resized, etc) will not be
    saved by default.
    Anyways, I think this task is not of highest priority, and we need more
    opinions to take decision

    2009/12/3 Mike Kienenberger <mkienenb@gmail.com>
    I agree with Andrey. It should be saved as part of the project. It
    doesn't make any sense to have a project-specific piece of information
    stored in preferences. If you copy your project to another machine,
    you lose the information. If you delete the project, the information
    remains in preferences even though the project is gone.

    You should mark it as ignored if you don't want to put it in your SCM
    or if the noise bothers you.

    On Thu, Dec 3, 2009 at 9:03 AM, Andrus Adamchik wrote:
    I agree with the premise, but I had bad experience with other ORM tools
    years ago that would save the layout together with the project, and then a
    single unintended mouse move results in making the project "dirty" and
    creates an underlying SCM change. IMO that was a distraction and created
    constant commit noise.

    So essentially managing a pretty layout is a parallel task to the main task
    of creating a model, and I don't want it to become a distraction. So maybe
    we can make it a project property (persist-layout: true|false (default))? If
    true, it will store the XML together with the project, if false, it will
    store it in local preferences?

    Andrus

    On Dec 3, 2009, at 3:47 PM, Andrey Razumovsky wrote:

    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 3:31 PM, Andrus Adamchik wrote:

    * saving graphs info as <domain_name>.graph.xml (and restoring). Note
    that
    this file will not be used in classic Cayenne runtime
    I think this can be tied to preferences and saved in ~/.cayenne/.
    Saving
    it
    in the project tree has SCM implications.
    I thought of that..
    Lets take your example. You've got an enormous project, so no layout can
    place entities without intersections. You spend half a day to organize
    it
    well.. Then what? How can other members of the team see your changes? It
    is
    even better when graph is in SCM - it is not a big file, and allows
    everyone
    to see it. Graph file is XML, so SVN should merge it correctly. The only
    thing you need is exclude it from packaged version of your project (if
    you
    want).

    At last resort you can add graph files to something like svn:ignore


    --
    Andrey
  • Andrus Adamchik at Dec 3, 2009 at 2:38 pm

    On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:

    It doesn't make any sense to have a project-specific piece of
    information
    stored in preferences.
    And still we do that a lot already. There's a bunch of per-screen
    Modeler preferences stored per project (and not in user visible XML
    files). If you move to another machine, you lose it.

    I think the difference here is in a mental view of the graph layout
    task. To you and Andrey it is a part of the ORM modeling work. To me
    it is not. It is a *local* user preference. Something a single
    developer would tweak to his or her liking, kind of like arranging
    icons on a desktop.

    Let me give you a few examples of why sharing a layout might be bad:

    * 2 developers on the project want to have different layouts, because
    they work with different parts of the model. So they group entities
    differently.

    * A single developer rearranges the layout multiple times during the
    day as he goes from one task to another.

    * 1 developer uses a 13" notebook, another - 31" screen. Developer 1
    has no choice, but to optimize the layout for his screen.

    Andrus
  • Ольга Ткачева at Dec 24, 2009 at 11:03 am
    excellent work, but I agree with Andrus.
    for example: yesterday I need only change DbEntity configuration, but I
    accidentally chose tab "graph". It create new graph.xml file,
    but I don't need it, it is really distraction and created commit noise.
    And I think if I will be use graph, my graphs configuration maybe be
    uncomfortable for other users.
    for example: I work only with 6 tables in DB and of course I will be placing
    it apart from all, but after update my tables change its places,
    it is really no good.



    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:

    It doesn't make any sense to have a project-specific piece of information
    stored in preferences.
    And still we do that a lot already. There's a bunch of per-screen Modeler
    preferences stored per project (and not in user visible XML files). If you
    move to another machine, you lose it.

    I think the difference here is in a mental view of the graph layout task.
    To you and Andrey it is a part of the ORM modeling work. To me it is not. It
    is a *local* user preference. Something a single developer would tweak to
    his or her liking, kind of like arranging icons on a desktop.

    Let me give you a few examples of why sharing a layout might be bad:

    * 2 developers on the project want to have different layouts, because they
    work with different parts of the model. So they group entities differently.

    * A single developer rearranges the layout multiple times during the day as
    he goes from one task to another.

    * 1 developer uses a 13" notebook, another - 31" screen. Developer 1 has no
    choice, but to optimize the layout for his screen.

    Andrus

    --
    Olga Tkacheva
  • Andrey Razumovsky at Dec 24, 2009 at 11:19 am
    Well, this task in not yet finished and unfortunately these days I'm very
    short of time. Guess we'll need to reconsider the saving mechanism later
    somehow. But note that if graphs aren't synchronized together with datamap
    conflicts may occur. Just imagine situation when someone removes an entity,
    but it still exists in your graph! It may be not so easy to handle all of
    them

    2009/12/24 Ольга Ткачева <tkachovaolga@gmail.com>
    excellent work, but I agree with Andrus.
    for example: yesterday I need only change DbEntity configuration, but I
    accidentally chose tab "graph". It create new graph.xml file,
    but I don't need it, it is really distraction and created commit noise.
    And I think if I will be use graph, my graphs configuration maybe be
    uncomfortable for other users.
    for example: I work only with 6 tables in DB and of course I will be
    placing
    it apart from all, but after update my tables change its places,
    it is really no good.



    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:

    It doesn't make any sense to have a project-specific piece of
    information
    stored in preferences.
    And still we do that a lot already. There's a bunch of per-screen Modeler
    preferences stored per project (and not in user visible XML files). If you
    move to another machine, you lose it.

    I think the difference here is in a mental view of the graph layout task.
    To you and Andrey it is a part of the ORM modeling work. To me it is not. It
    is a *local* user preference. Something a single developer would tweak to
    his or her liking, kind of like arranging icons on a desktop.

    Let me give you a few examples of why sharing a layout might be bad:

    * 2 developers on the project want to have different layouts, because they
    work with different parts of the model. So they group entities
    differently.
    * A single developer rearranges the layout multiple times during the day as
    he goes from one task to another.

    * 1 developer uses a 13" notebook, another - 31" screen. Developer 1 has no
    choice, but to optimize the layout for his screen.

    Andrus

    --
    Olga Tkacheva


    --
    Andrey
  • Andrus Adamchik at Dec 24, 2009 at 12:58 pm
    I guess the timeline for this is ~3.1M1 (whenever that might be...
    still I am eager to try the new DI stuff in my apps, so once the
    configuration switch is over I was going to suggest an M1). In any
    event this gives us some breezing room.

    Good point on the file falling out of sync. I guess the graph load
    algorithm will have to handle that - ignoring deleted/renamed
    entities, auto-positioning new entities. Not sure if it stores the
    connectors positions as well, but if it does, it can apply the same
    approach - if both endpoint entities are still there, keep it,
    otherwise remove it.

    Andrus

    On Dec 24, 2009, at 1:18 PM, Andrey Razumovsky wrote:
    Well, this task in not yet finished and unfortunately these days I'm
    very
    short of time. Guess we'll need to reconsider the saving mechanism
    later
    somehow. But note that if graphs aren't synchronized together with
    datamap
    conflicts may occur. Just imagine situation when someone removes an
    entity,
    but it still exists in your graph! It may be not so easy to handle
    all of
    them

    2009/12/24 Ольга Ткачева <tkachovaolga@gmail.com>
    excellent work, but I agree with Andrus.
    for example: yesterday I need only change DbEntity configuration,
    but I
    accidentally chose tab "graph". It create new graph.xml file,
    but I don't need it, it is really distraction and created commit
    noise.
    And I think if I will be use graph, my graphs configuration maybe be
    uncomfortable for other users.
    for example: I work only with 6 tables in DB and of course I will be
    placing
    it apart from all, but after update my tables change its places,
    it is really no good.



    2009/12/3 Andrus Adamchik <andrus@objectstyle.org>
    On Dec 3, 2009, at 4:22 PM, Mike Kienenberger wrote:

    It doesn't make any sense to have a project-specific piece of
    information
    stored in preferences.
    And still we do that a lot already. There's a bunch of per-screen
    Modeler
    preferences stored per project (and not in user visible XML
    files). If you
    move to another machine, you lose it.

    I think the difference here is in a mental view of the graph
    layout task.
    To you and Andrey it is a part of the ORM modeling work. To me it
    is not. It
    is a *local* user preference. Something a single developer would
    tweak to
    his or her liking, kind of like arranging icons on a desktop.

    Let me give you a few examples of why sharing a layout might be bad:

    * 2 developers on the project want to have different layouts,
    because they
    work with different parts of the model. So they group entities
    differently.
    * A single developer rearranges the layout multiple times during
    the day as
    he goes from one task to another.

    * 1 developer uses a 13" notebook, another - 31" screen. Developer
    1 has no
    choice, but to optimize the layout for his screen.

    Andrus

    --
    Olga Tkacheva


    --
    Andrey

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdev @
categoriescayenne
postedDec 3, '09 at 1:31p
activeDec 24, '09 at 12:58p
posts13
users4
websitecayenne.apache.org

People

Translate

site design / logo © 2022 Grokbase