You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by Denis Zvonov <zv...@mobilae.ru> on 2005/04/29 09:44:11 UTC
Versioning: Conent cloning on PROPPATCH.
Hi guys,
We found that when PROPPATCH is executed on a versionable resource a new
version (new file or VERSION_CONTENT record in case of RDBMS) of content
is produced too. This leads to inacceptable cloning of content which
leads to storage size growth. When we plan to store thousands or even
millions of files with the total volume of tenths of gigabytes, this
cloning becomes a very unpleasant...
Can there be a way to write a storage or any other way not to clone
!_unchanged_! content?
Also there is another issue with Slide implementation. When we configure
Slide to store content in filesystem and all other things in Oracle,
content of previous versions is stored in Oracle anyway. There should be
allowed some history_content_store pluggable, I think.
Another issue with Oracle store implementation. Revoking of privileges
from resources has error in SQL statement and does not work.
We use Slide 2.1
Best regards.
Denis.
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: Versioning: Conent cloning on PROPPATCH.
Posted by Andy Depue <an...@marathon-man.com>.
The ideal here, of course, would be for versioning to store deltas. If a
property changes, record the change in the property alone, etc. If the
content is text and the content changes, store a diff, not a new copy (much
like CVS). If the content is binary, then store a binary delta. There are
open source Java projects available for performing binary deltas, such as
http://sourceforge.net/projects/xdelta
- Andy
On Friday 29 April 2005 12:44 am, Denis Zvonov wrote:
> Hi guys,
>
> We found that when PROPPATCH is executed on a versionable resource a new
> version (new file or VERSION_CONTENT record in case of RDBMS) of content
> is produced too. This leads to inacceptable cloning of content which
> leads to storage size growth. When we plan to store thousands or even
> millions of files with the total volume of tenths of gigabytes, this
> cloning becomes a very unpleasant...
>
> Can there be a way to write a storage or any other way not to clone
> !_unchanged_! content?
>
>
> Also there is another issue with Slide implementation. When we configure
> Slide to store content in filesystem and all other things in Oracle,
> content of previous versions is stored in Oracle anyway. There should be
> allowed some history_content_store pluggable, I think.
>
> Another issue with Oracle store implementation. Revoking of privileges
> from resources has error in SQL statement and does not work.
>
> We use Slide 2.1
>
> Best regards.
> Denis.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org
Re: Versioning: Conent cloning on PROPPATCH.
Posted by Martin Kalén <mk...@apache.org>.
Denis Zvonov wrote:
> Another issue with Oracle store implementation. Revoking of privileges
> from resources has error in SQL statement and does not work. We use Slide 2.1
Yes, there was a missing right parenthesis in the SQL since one of the Slide
developers (presumable without the possibility to test on Oracle) applied
a user-submitted patch in CVS.
I have already sent in a simple patch for this that Stefan Lützkendorf applied,
so this is fixed in CVS (v2.2pre). Applies to Oracle and DB2, that share
the same code for the SQL-generation for those calls.
Another user noted a similar issue for PostgreSQL, where I wrapped his
suggestions up in another patch and attached it to the bugzilla issue (#34343).
This one it still pending (not yet reviewed/commited by someone with
slide CVS-karma). This should however only apply to PostgreSQL.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org