Home » Modeling » EMF » [CDO] Being able to retrieve ResourcePath from a MemStore implementation
| | | | |
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424755 is a reply to message #424754] |
Tue, 04 November 2008 23:24   |
 Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Good!!
NOw when users ask the following:
/aaa/bbb/ccc
This contains 4 objects :
A- CDOResource (RootResource) name = null, folderID =null
B- CDOResourceFolder name = aaa, folderID =null
C- CDOResourceFolder name = bbb, folderID = B
D- CDOResource name = ccc, folderID = C
The client would call first QUeryResource.. after it could call
QUeryResource or readRevision!! It depends of many things.
When folder==null and name == null this means it looks for the RootResource!
Let me know if you need more advices
Simon
Now
kaab wrote:
> Hi Simon,
> Thanks for all your help,
> I am making some progress using the path reconstruction, and fully
> implemented a backed version of the Store in the filesystem.
> The second part of my work is when a user try to load a resource, in
> this case I'm not sure I understand the way MemStore behaves. The user
> enters a path trying to load a resource for example "/aaa/bbb/ccc", on
> the server side I get a QueryResourceContext with the first part of the
> name and null as the folderID,after that the MemStore is not called
> anymore and the resource is loaded, so I don't know how to determine the
> full path for a query when a user does one.
>
> Anyone can advice on that matter ?
>
> Thank you very much,
>
|
|
| | | | | |
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424764 is a reply to message #424761] |
Wed, 05 November 2008 07:40 |
|
Kaab,
Please note that moving resources or folders (from one containing folder
to another) will change the path of this and all contained
CDOResourceNodes. This might be an expensive operation in the file
system. The only property of an object that never changes is the CDOID.
If you don't really need a 1:1 human readable file system structure I'd
recommend not to use the "path" feature of CDOResourceNode as part of
the file name. If you just want to have some structure on the file
system so the the directories don't grow to large I'd recommend to use
something like the following:
file system path := f( CDOID )
As the store implementor you're free to choose any implementation
approach (class/format) for your CDOIDs. Since the MEMStore derives from
LongIDStore I assume your CDOIDs are internally represented by long
integer values. A simple example for constructing a file system
structure is:
2764183 (CDOID)
000000002764183 (id as padded string)
000/000/002/764/183 (file system path)
Of course there are many other functions imaginable...
Cheers
/Eike
----
http://thegordian.blogspot.com
kaab schrieb:
> Which part of the MEMStore you did change by your implementations? Are
> you sure that populating the objects is done correctly ?
>
> ->The only change I made so far is on the public void
> write(CommitContext context) of my StoreAccessor.
>
> I call a static method to retrieve the list of newObjects. By parsing
> this list, I construct the path, after that the resources are stored
> in the filesystem.
> Every revision is stored in its corresponding cdoPath followed by a
> folder named with the CDOID, every revision file on the file system
> is named with their version.
> For example for Revision with CDOID 2 of resource /aaa/bbb/ccc :
> The full path to the revision on the file sytem will be :
> C:/CDOSTORE/cdoPath/CDOID/RevisionVersion.rev
> eq
> C:/CDOSTORE/aaa/bbb/ccc/2/1.rev
>
> For every resourceFolder, I store the revisionResource in the folder
> using its ID so for resourceFolder named bbb with CDOID 1, the full
> path on the filesystem will be :
>
> C:/CDOSTORE/aaa/bbb/1.filerev
>
> I store the Resource revisions using .res same path as regular revisions.
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424918 is a reply to message #424763] |
Mon, 10 November 2008 15:54 |
kaab 
Messages: 43
Registered: July 2009 |
Member |
|
|
Hi guys,
Thanks for all your help and information.
I'm sorry to get back to you so late, I've been sick last week and I just
got back to work.
I'm doing some debug after I changed the path to use the CDOID only,
instead of keeping complete path, which would be bad in case of moving
resources, like Eike mentioned.
Right now, I'm using a seperate folder for the RootResource and the padded
string to store the revisions. I've been thinking in storing
RootResourceFolders by their names in some file in order to keep track of
the correpondancy between TopLevel reource folder Names and CDOIDs, cause
I've noticed that they are also queried trough queryResources (as long as
the RootRessource) and so they are queried by their names and not their
CDOIDs, is this Right ?
Thanks,
|
|
|
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424919 is a reply to message #424918] |
Mon, 10 November 2008 16:37 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Hi Kaab,
Happy to hear that you are feeling better!! :-)
kaab wrote:
> Hi guys,
> Thanks for all your help and information.
> I'm sorry to get back to you so late, I've been sick last week and I
> just got back to work. I'm doing some debug after I changed the path to
> use the CDOID only, instead of keeping complete path, which would be bad
> in case of moving resources, like Eike mentioned. Right now, I'm using a
> seperate folder for the RootResource and the padded string to store the
> revisions. I've been thinking in storing RootResourceFolders by their
> names in some file in order to keep track of the correpondancy between
> TopLevel reource folder Names and CDOIDs, cause I've noticed that they
> are also queried trough queryResources (as long as the RootRessource)
> and so they are queried by their names and not their CDOIDs, is this
> Right ?
Right but...
They could be queried by CDOID as well. It depends how the client
request an objects.
getResource("/aa/aa/bb/cc") // By Name
getObject(id) // by id.. could be a resource.
Simon
> Thanks,
>
>
>
|
|
| |
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424922 is a reply to message #424920] |
Mon, 10 November 2008 19:40 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
Hi Kaab,
Which errors you are noticing? Stack trace will be good!! :-)
THe code you showed me could be good or not.
In which context you are using it in the server side. I mean... WHat are
the Request/Indication are you using it for ?
SImon
kaab wrote:
> Hi,
> I'm sorry to bother you so often, but after I've prepared to run a full
> test, I'm noticing a lot of errors when reading CDORevisions, speacially
> for resolving cdoClassRefs. The way we read and write revisions is
> mainly inspired from CDO code. And it is now implemented this way :
>
> final FileOutputStream output = new FileOutputStream(f);
> final ExtendedDataOutputStream ext = ExtendedDataOutputStream.wrap(output);
> final CDODataOutputImpl cdodo = new CDODataOutputImpl(ext) {
> // Not sure about these two
> @Override
> protected CDOPackageURICompressor getPackageURICompressor() {
> return (CDOPackageURICompressor)session;
> }
>
> @Override
> public CDOIDProvider getIDProvider() {
> return (CDOIDProvider)session;
> }
> };
> ((CDORevisionImpl)revision).write(cdodo, CDORevision.UNCHUNKED);
>
> If this code is not OK, than I would really appreciate your suggestions
> to serialize the revisions into the filesystem. This code was tested and
> was working but it now causing problems, so I would like to make sure
> it's safe using it.
>
> Thanks,
>
|
|
| | | |
| Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424963 is a reply to message #424920] |
Wed, 12 November 2008 07:40 |
|
Kaab,
The special CDODataInputStream and CDODataOutputStream were designed to
be used for data transfer over the network. I think it can be used for
transfer to/from files as well but the package URI compressor does not
make sense then because it relies on a compressor being available at the
other side of the stream as well. Please file a Bugzilla so that I can
change the code to ignore null values for package URI compressors and
just write/read an uncompressed URI in that case. An IDProvider is only
needed at client side when committing a transaction. At the server side
you can implement an IDProvider as the identity function (just return
the down casted argument).
Cheers
/Eike
----
http://thegordian.blogspot.com
kaab schrieb:
> Hi,
> I'm sorry to bother you so often, but after I've prepared to run a
> full test, I'm noticing a lot of errors when reading CDORevisions,
> speacially for resolving cdoClassRefs. The way we read and write
> revisions is mainly inspired from CDO code. And it is now implemented
> this way :
>
> final FileOutputStream output = new FileOutputStream(f);
> final ExtendedDataOutputStream ext =
> ExtendedDataOutputStream.wrap(output);
> final CDODataOutputImpl cdodo = new CDODataOutputImpl(ext) {
> // Not sure about these two
> @Override
> protected CDOPackageURICompressor getPackageURICompressor() {
> return (CDOPackageURICompressor)session;
> }
>
> @Override
> public CDOIDProvider getIDProvider() {
> return (CDOIDProvider)session;
> }
> };
> ((CDORevisionImpl)revision).write(cdodo, CDORevision.UNCHUNKED);
>
> If this code is not OK, than I would really appreciate your
> suggestions to serialize the revisions into the filesystem. This code
> was tested and was working but it now causing problems, so I would
> like to make sure it's safe using it.
>
> Thanks,
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Tue Apr 16 22:35:24 GMT 2024
Powered by FUDForum. Page generated in 0.40625 seconds |
] 
Search
Help
Register
Login
Home
