Eclipse Community Forums: EMF » [CDO] Being able to retrieve ResourcePath from a MemStore implementation

Home » Modeling » EMF » [CDO] Being able to retrieve ResourcePath from a MemStore implementation

[CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424741]

Tue, 04 November 2008 10:51

Eclipse User

Hi,

I am trying to write a custom implementation of MemStore, but I've been
struggling with one issue I have.
I need to able to get the path of the revisions I am willing to write when
write(CommitContext) of the MemStoreAccessor is called.
The CommitextContext contains the new and dirty Revisions but not the
path, even by digging into code, I am not able to determine the path of
the revisions that need to be written from a pure cdo server perspective
which I need to be able to implement our own version of the MemStore.

Any help with this will be much appreciated,

Thanks,

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424742 is a reply to message #424741]

Tue, 04 November 2008 11:06

Eclipse User

hi Kaab,

Path is a derived features. So it is not included into the CDORevision.
It will not be persisted.

The path can be calculated from the folderID and name features.

Since it will load objects.. I'm not if it is what you are looking for.

Simon

kaab wrote:
> Hi,
> I am trying to write a custom implementation of MemStore, but I've been
> struggling with one issue I have. I need to able to get the path of the
> revisions I am willing to write when write(CommitContext) of the
> MemStoreAccessor is called. The CommitextContext contains the new and
> dirty Revisions but not the path, even by digging into code, I am not
> able to determine the path of the revisions that need to be written from
> a pure cdo server perspective which I need to be able to implement our
> own version of the MemStore.
> Any help with this will be much appreciated,
> Thanks,
>
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424743 is a reply to message #424742]

Tue, 04 November 2008 11:27

Eclipse User

I'm trying to rewrite the MemStore in order to be able to store some of
its revisions into the file system, probably using the path provided by
the user. The same path has to be used to retrieve these resources.
Right now using a method I've created, I've been able to recreate the path
for a commit of a new Resource by checking isFolder() property of each
resource and then retrieving a part of the path and appending it to the
fullPath. I'm not sure if this method will work for an update, are the
folder resources updated too when one of their contained EObjects are ?.
Also the folderID is not the same after shutdown the server and restarting
it, that is why I can't rely on the FolderID.

My objectif is to simply extend the MemStore to able to store some file
into the filesystem, using the path provided by the user when he does the
commit.
Any remark or advice will be welcome,
Thanks,

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424744 is a reply to message #424743]

Tue, 04 November 2008 11:34

Eclipse User

yes it will work for an update.

Be careful with FolderID feature since that feature is describe as
isContainer = true.
You will always get null.
For now uses revisionData.getCOntainerID() for the folderID.

The following bugzilla should fix it... but it is in progress :
250977: revision.get(CDOFeature) doesn't work if container property is
enabled for that feature
https://bugs.eclipse.org/bugs/show_bug.cgi?id=250977

After that if you cannot rely on folderID.. (or in this case
getContainerID) ... we have a problem and should fix it ! :-)

Simon

kaab wrote:
> I'm trying to rewrite the MemStore in order to be able to store some of
> its revisions into the file system, probably using the path provided by
> the user. The same path has to be used to retrieve these resources.
> Right now using a method I've created, I've been able to recreate the
> path for a commit of a new Resource by checking isFolder() property of
> each resource and then retrieving a part of the path and appending it to
> the fullPath. I'm not sure if this method will work for an update, are
> the folder resources updated too when one of their contained EObjects
> are ?. Also the folderID is not the same after shutdown the server and
> restarting it, that is why I can't rely on the FolderID.
>
> My objectif is to simply extend the MemStore to able to store some file
> into the filesystem, using the path provided by the user when he does
> the commit.
> Any remark or advice will be welcome,
> Thanks,
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424754 is a reply to message #424744]

Tue, 04 November 2008 18:03

Eclipse User

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 #424755 is a reply to message #424754]

Tue, 04 November 2008 18:24

Eclipse User

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 #424757 is a reply to message #424755]

Tue, 04 November 2008 21:33

Eclipse User

Hi Simon,

None of the getters in the Store or the Accessor are called, only the root
folderResource is queried, and no later call to the getRevision is made. I
tried setting
<property name="currentLRUCapacity" value="0"/>
<property name="revisedLRUCapacity" value="0"/>
but that makes no difference.
Can you advise me on a way to shut down the cache so that resources will
all be queried trough the store.

Thanks again for your help,

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424758 is a reply to message #424757]

Tue, 04 November 2008 21:55

Eclipse User

kaab wrote:
> Hi Simon,
> None of the getters in the Store or the Accessor are called, only the
> root folderResource is queried, and no later call to the getRevision is
> made. I tried setting
> <property name="currentLRUCapacity" value="0"/>
> <property name="revisedLRUCapacity" value="0"/>
You have cache in the server and in the client.

> but that makes no difference. Can you advise me on a way to shut down
> the cache so that resources will all be queried trough the store.
>
It probably stop at the client?
You can use
In the client:
((CDORevisionResolverImpl)session.getRevisionManager()).getC ache().clear();

In the server
((CDORevisionResolverImpl)getRepository().getRevisionManager ()).getCache().clear();

I think that maybe the store do not provide the correct RootResource ?
Which part of the MEMStore you did change by your implementations? Are
you sure that populating the objects is done correctly ?

I suspect the object that is in the cache.. is exactly the same...

How do you provide the version for revision in your CUstom memstore ?

> Thanks again for your help,
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424761 is a reply to message #424758]

Tue, 04 November 2008 22:26

Eclipse User

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.

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424762 is a reply to message #424757]

Wed, 05 November 2008 02:17

Eclipse User

Kaab,

A value of zero for any of the capacity properties really means "no
eviction" rather than "no caching".
This is a dangerous setting because it will constantly grow the cache
(unless you have no transactions).

Cheers
/Eike

----
http://thegordian.blogspot.com

kaab schrieb:
> Hi Simon,
> None of the getters in the Store or the Accessor are called, only the
> root folderResource is queried, and no later call to the getRevision
> is made. I tried setting
> <property name="currentLRUCapacity" value="0"/>
> <property name="revisedLRUCapacity" value="0"/>
> but that makes no difference. Can you advise me on a way to shut down
> the cache so that resources will all be queried trough the store.
>
> Thanks again for your help,
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424763 is a reply to message #424757]

Wed, 05 November 2008 02:19

Eclipse User

Kaab,

Comments below...

kaab schrieb:
> [...] Can you advise me on a way to shut down the cache so that
> resources will all be queried trough the store.
If you need something like a NOOPRevisionCache I suggest you file an
enhancement request.

Cheers
/Eike

----
http://thegordian.blogspot.com

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424764 is a reply to message #424761]

Wed, 05 November 2008 02:40

Eclipse User

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.
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424918 is a reply to message #424763]

Mon, 10 November 2008 10:54

Eclipse User

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 11:37

Eclipse User

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 #424920 is a reply to message #424919]

Mon, 10 November 2008 14:18

Eclipse User

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 #424922 is a reply to message #424920]

Mon, 10 November 2008 14:40

Eclipse User

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 #424923 is a reply to message #424922]

Mon, 10 November 2008 14:57

Eclipse User

Using it only locally, the function mentioned in my last post is called
whenever a revision is to be persisted, when loading a resource I call a
similar code with CDODataInput. I'm sure what you mean by
request/indication but I'm not using that at all, should I ?
When I try to read a resource after I saved it to the filesystem this way,
I get the following stacktrace, the class ref is not resolved and thus the
values are not neither :

java.lang.NullPointerException
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .readValues(CDORevisionImpl.java:578)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:135)
at
com.castortech.cdo.memstore.util.BackedFileStoreAccessor.loa dRevision(BackedFileStoreAccessor.java:135)
at
com.castortech.cdo.memstore.IrisMemStoreAccessor.readRevisio n(IrisMemStoreAccessor.java:119)
at
org.eclipse.emf.cdo.internal.server.RevisionManager.loadRevi sion(RevisionManager.java:202)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionReso lverImpl.getRevision(CDORevisionResolverImpl.java:94)
at
org.eclipse.emf.cdo.internal.common.revision.CDORevisionReso lverImpl.getRevision(CDORevisionResolverImpl.java:79)
at
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.getRevision(LoadRevisionIndication.java:177)
at
org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:147)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:151)
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:52)
at
org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:206)
at org.eclipse.net4j.signal.Signal.run(Signal.java:187)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424925 is a reply to message #424923]

Mon, 10 November 2008 15:09

Eclipse User

Ah Ok!!

You should not used the sessionpackageURICompressor.. since the
compression keep value internally... and at read time they will not be
valid anymore.

@Override
protected CDOPackageURICompressor getPackageURICompressor() {
return (CDOPackageURICompressor)session;

Please used this one instead
CDOPackageURICompressor.UNCOMPRESSED

Simon

kaab wrote:
> Using it only locally, the function mentioned in my last post is called
> whenever a revision is to be persisted, when loading a resource I call a
> similar code with CDODataInput. I'm sure what you mean by
> request/indication but I'm not using that at all, should I ?
> When I try to read a resource after I saved it to the filesystem this
> way, I get the following stacktrace, the class ref is not resolved and
> thus the values are not neither :
> java.lang.NullPointerException
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl .readValues(CDORevisionImpl.java:578)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionImpl . <init>(CDORevisionImpl.java:135)
>
> at
> com.castortech.cdo.memstore.util.BackedFileStoreAccessor.loa dRevision(BackedFileStoreAccessor.java:135)
>
> at
> com.castortech.cdo.memstore.IrisMemStoreAccessor.readRevisio n(IrisMemStoreAccessor.java:119)
>
> at
> org.eclipse.emf.cdo.internal.server.RevisionManager.loadRevi sion(RevisionManager.java:202)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionReso lverImpl.getRevision(CDORevisionResolverImpl.java:94)
>
> at
> org.eclipse.emf.cdo.internal.common.revision.CDORevisionReso lverImpl.getRevision(CDORevisionResolverImpl.java:79)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.getRevision(LoadRevisionIndication.java:177)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.LoadRevisionInd ication.responding(LoadRevisionIndication.java:147)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOServerIndica tion.responding(CDOServerIndication.java:151)
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:52)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CDOReadIndicati on.execute(CDOReadIndication.java:36)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:206)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:187)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unkno wn
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
>
>
>
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424926 is a reply to message #424925]

Mon, 10 November 2008 16:02

Eclipse User

Thank you !!!
Just got the read and write working with your little hint. I can't thank
you enough for all the help and responsiveness.
You guys rule !

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424963 is a reply to message #424920]

Wed, 12 November 2008 02:40

Eclipse User

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,
>

Re: [CDO] Being able to retrieve ResourcePath from a MemStore implementation [message #424964 is a reply to message #424963]

Wed, 12 November 2008 02:43

Eclipse User

Eike Stepper schrieb:
> 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.
Argh, I did not remember that we have a NOOP implementation of the
package URI compressor.
Simon's suggestion to use CDOPackageURICompressor.UNCOMPRESSED is of
course better than special handling of null values.
Please do not file a Bugzilla ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com

Previous Topic:	[EMF] Problems registering package namespaces.
Next Topic:	[CDO] Optimization

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 19:12:40 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter