Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] CDOResource path ([CDO] CDOResource path )
[CDO] CDOResource path [message #997143] Thu, 03 January 2013 22:54 Go to next message
Andrew Whelan is currently offline Andrew Whelan
Messages: 69
Registered: October 2012
Location: Syracuse NY
Member
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 #997178 is a reply to message #997143] Fri, 04 January 2013 09:51 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5537
Registered: July 2009
Senior Member
Am 03.01.2013 23:54, schrieb Andrew Whelan:
> 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?
You cannot store (model) content in "/". Similarly you cannot store text in a local file named "/".

"/" refers to the (internal) root resource, which must not contain model content, just folders and resources.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDOResource path [message #997253 is a reply to message #997178] Fri, 04 January 2013 17:53 Go to previous messageGo to next message
Andrew Whelan is currently offline Andrew Whelan
Messages: 69
Registered: October 2012
Location: Syracuse NY
Member
I guess I'm just finding it confusing from a pure database context. 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. 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?

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?

Thanks.
Sorry for sounding like such a newbe Smile
Re: [CDO] CDOResource path [message #997384 is a reply to message #997253] Mon, 07 January 2013 09:23 Go to previous messageGo to next message
Christoph Keimel is currently offline Christoph Keimel
Messages: 367
Registered: December 2010
Location: Germany
Senior Member
Hi Andrew

I was facing the same question not long ago. I have a similar background, so the concept of CDOResource was new to me. I also started out with a single resource for everything. After some playing around, I changed this concept. I am now using a different resource for every containment hierarchy. Since I don't use containment very often, this results in having a different resource for most tables. I use the name of the EClass as an identifier for the resource.

The benefit of this approach is that it is easy to get all children of a resource (i.e. get all countries for a drop down list) and it is also easy to listen to changes to specific resources (i.e. refresh the drop down list in an already open editor).

Greetings
Christoph
Re: [CDO] CDOResource path [message #997412 is a reply to message #997384] Mon, 07 January 2013 11:06 Go to previous message
Christophe Bouhier is currently offline Christophe Bouhier
Messages: 937
Registered: July 2009
Senior Member
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 08:36 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5537
Registered: July 2009
Senior Member
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
Previous Topic:e(fx)clipse 0.8.0 - EMF-Edit support for JavaFX
Next Topic:Copying contained objects
Goto Forum:
  


Current Time: Mon Oct 20 18:17:12 GMT 2014

Powered by FUDForum. Page generated in 0.04154 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software