The proposal for this project can be found at http://wiki.apache.org/general/SummerOfCode2006/cayenne-rop-proposal
. The example app is now a visual database editor, both as an example and a framework. It is being developed in Eclipse using GEF.
A sandbox SVN repository can be found at https://svn.objectstyle.org/repos/soc/trunk/cayenne-rop/ - this app is under rop-browser.
Progress
The Control Panel is opened using the menu Window->Show View->Other...>ROP Browser>Control Panel. The server URL is entered, connection is made and a query is selected to run.
The picture below shows a small database completely expanded. The blue element is the root of the query. The yellow elements are collections, the result of following 1-n relationships which return more than one record. The grey elements are single objects, either 'popped out' from collections, the result of 1-1 relationships or the result of 1-n relationships returning only one record. Solid lines indicate that there is a relationship between the objects, and the arrowhead indicates the direction of expansion. Double arrowheads indicate a relationship which has been expanded both ways. Dashed lines indicate that the element is comes from the collection. The small label at the bottom right is a tooltip from the nearest relationship.
Relationships are expanded by selecting the appropriate element (selection handles don't appear at present) and clicking the relationship name. Double clicking a collection will cycle through its constituent elements, which can then be 'popped out' by clicking on the 'Pop Out' button.
Values can be edited by selecting an element and using the Eclipse properties view.
Design
Pertinent excerpts from Andrus' mailing list messages relating to this:
------------
Not as a development tool, but as a framework for building a multi-user visual graph manager based on Cayenne model. It can have functionality similar to this Visual Graph Manager:
- A generic GUI application that connects to Cayenne web service
- A panel to select a mapped named query from the list and run it against the server
- A panel to display a graph of objects that expands when relationships are clicked.
- An ability to select a node on the graph, and edit its properties (we can omit relationship editing in version 1.0)
- An ability to save the whole thing to the server
- Change notifications - propagate the changes made to objects in one client to other clients viewing the same graph (this is the cool thing about ROP - it does that for you automatically with XMPP)
- A sample Cayenne model that demonstrates the above capabilities
-------------
Showing *all* object graph means showing the entire database. This is certainly NOT how you want to do it. So let me reiterate: You'd start with a list of objects fetched for a given query (i.e. a small subset of a db), and then expand the graph on demand as the user clicks on a relationships of a specific objects. Cayenne yields itself extremely well to this type of navigation, lazily resolving relationships behind the scenes (so instead of "instance data won't be loaded" you may say "relationship data won't be loaded").
E.g. in response to a query a user may get a list of artists (a1, a2, ... an). (S)he clicks on some artist's "paintings" relationships, this would expand a list of paintings for this artist only, and so on.
For version 1.1, we may also take query "prefetching" into account to show more than one kind of objects on the initial graph.
Can you point me in the right direction for Cayenne's XML file parsing code please? Does Cayenne maintain an accessible (to the ROP client) model of the object graph, or will I have to build one based upon the XML file?
Cayenne provides all the metadata to you, on the client as well as on the server. And you don't need to parse any XML. ObjectContext.getEntityResolver() is what you are looking for.
Old
Things being what they are, the Confluence editor project hit a wall (well, more like a three foot high speed bump - not insurmountable, but not pleasant either). The problem is that Confluence is not merely a layer on the DB, it wraps the DB and relies on all changes to the DB coming through the interfaces it exposes. Not unreasonable, but not very good for what we were aiming for. There was a potential solution available - writing an RPC plugin exposing a content refresh method - but it was felt better to continue with the project above. Much Cayenne-related experience was gained.
A sandbox SVN repository can be found at https://svn.objectstyle.org/repos/soc/trunk/cayenne-rop/. There are folders for cws (the server side, mapping the Confluence database to objects) and crop (the GUI application for editing Confluence).
The server side bits and pieces seem to be running. At this stage it is not clear to me (as a Cayenne newbie) whether they are running completely correctly. Time - and advice from the dev team - will tell I'm sure.
Confluence discoveries:
- Titles are not case sensitive ie Formatting Content == formatting content.
- Spaces in titles are stored in the database as spaces but translated to + in URLs.
- No characters (incl +) are allowed in titles
- Content records for pages only use the following fields: contentid, contenttype == PAGE, title, version, creator, creationdate, lastmodifier, lastmoddate, versioncomment, prevver (the contentid of the most recent entry [strange name] ), contentstatus. spaceid and parentid are also used for the most recent entry (prevver is null).
- When an edit is made, the current version gets copied to a new record and replaced with the new version; same applies to bodycontent (they are moved in parallel).
- Confluence doesn't query the DB for the next contentid every time it inserts a record; it gets it the first time and caches it. This means that inserting a new record in the database will cause problems with Confluence's cache. Solution? Hmmm...one possibility is starting Cayenne's auto pk sequence from a very high value (a billion or so).
Progress
The CWS side of things seems to be running fine, although it is bound to need periodic updates as the object models change.
The RCP side is progressing: it now contains a browser with an 'Edit Page' button. This button opens the current page for editing, which currently displays the title and the content of the page. Changes cannot be saved at present. Multiple pages can be viewed and edited at once.
