| [CDO] CDOResource path [message #997143] |
Thu, 03 January 2013 17:54  |
Eclipse User |
|
|
|
Hello,
In order to perform some CDO database functionality you need to get or create a resource (CDOResource). This involves a path. We currently only see the need for one resource and are not sure why we would benefit from creating a path that is anymore than "/". Is there a good reason for giving it a name (such as "/res1" in the demos) other than "/" in our case?
Thanks
-Andrew
|
|
|
|
|
|
| Re: [CDO] CDOResource path [message #997412 is a reply to message #997384] |
Mon, 07 January 2013 06:06  |
| Eclipse User |
|
|
|
Hi,
It helps me to think of a CDOResource as an entry point into the model. So instead of modeling this entry point with a separate class (In the Library Example, the 'Library' would be an entry point), simply define books and authors and stuff books into getOrCreateResource(Books.getClass().getName()).
Next time you need your books as objects, it's easy to remember and you know where they are. That's it really.
Rgds Christophe
|
|
|
| Re: [CDO] CDOResource path [message #997646 is a reply to message #997253] |
Sat, 05 January 2013 03:36 |
| Eclipse User |
|
|
|
Am 04.01.2013 18:53, schrieb Andrew Whelan:
> I guess I'm just finding it confusing from a pure database context.
I see. But CDO is primarily a modeling technology. Relational databases are just one possible type of physical storage
used with CDO.
> I understand that you would need a path/URI to use the out of the box method of the EMF persistence mechanism of
> saving data to a file. This is because you need a URI to save it too.
Yes, and to load it from. I like this definition: "A CDOResource is an EObject with a well-known *name* that can serve
as an entry point into the EObject graph". Note that this is not exactly true outside of CDO because elsewhere a
Resource is typically not an EObject.
> I also see value in the idea of storing objects in different repositories. So then if I am only using one repository,
> I would just use the same repository every time?
That sounds like a trick question :P
> CDOResource resource = transaction.getOrCreateResource("/repo1");
> And then use this resource to add data to and get data from the one repository (repo1). Does this make sense or am I
> missing something?
Hmm. From an EMF point of view a resource has a URI. In CDo this URI consists of three parts, the "cdo://" prefix, the
repository UUID and the path of the resource within that repository, for example: cdo://repo1/path/to/my/resource
Note that "repo1" is usually a *name* of a repository, not it's UUID. Names are required to be unique in the scope of an
IAcceptor. In addition a repository always has a UUID that's used in client-side URIs (no network details are needed to
make URIs unique). But in the common case that an application system only uses one repository (more correct: one
host/acceptor) there's no need to pollute URIs with long and ugly UUIDs. So most people override the UUID to be the *name* .
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.36185 seconds
Home