2 Dec
2010
2 Dec
'10
11:45 p.m.
I now have a working model of attachment storage in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
This introduces a 2 major changes to the storage direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the storage
engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I intend
to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
WDYT?
Caleb
PS. This code currently contains no tests, I do not want to go any further until I know
this path is
agreed upon.
3 Dec
3 Dec
8:55 a.m.
On 12/03/2010 12:45 AM, Caleb James DeLisle wrote:
I now have a working model of attachment storage in
the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
This introduces a 2 major changes to the storage direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
Maybe you should make the start method final.
NOTE: I have TransactionRunnable as a nested class
while it is in development and I intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
WDYT?
Looks good to me, +1.
Thanks,
Marius
Caleb
PS. This code currently contains no tests, I do not want to go any further until I know
this path is
agreed upon.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:13 a.m.
Hi,
On Fri, Dec 3, 2010 at 08:55, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Looks promising to me as well... Is there a way I could get a version to
test without having to build XWiki?
Guillaume
On 12/03/2010 12:45 AM, Caleb James DeLisle wrote:
Right now, where are all the versions of a given file stored and under which
name? Is there
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_1.jpg
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_2.jpg
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_3.jpg
and so on?
If not, where are previous versions of the file stored?
I now have a working model of attachment storage
in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it
simply by adding the .jar
file to the /lib/ dir and
changing the attachment store in the xwiki.cfg.
This introduces a 2 major changes to the storage direction which I want
to go
over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which
does a
job inside of a
transaction, it also provides hooks for rollback,
commit and complete
events. The underlying concept
is that code which is to run inside of a
transaction is passed as an
object to the storage engine
where the transaction is opened and it is run.
This will make the
exception catching generic for all
storage and Transaction is an interface
independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
Maybe you should make the start method final.
NOTE: I have TransactionRunnable as a nested
class while it is in
development and I intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a
document
called
xwiki:Main.WebHome will be stored in a file at
the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a
character
which is URL
invalid and thus insures that if nested spaces
are implemented, a
document called
xwiki:Main.WebHome.attachments will not cause a
collision.
The "attachments" directory is a directory dedicated to attachments for
the given document.
The "30579.jpg" directory under the
attachments directory is dedicated to
all information related to
that directory. This opens the possibility for
attachment history to be
stored along side the
attachment content.
WDYT?
Looks good to me, +1.
Thanks,
Marius
Caleb
PS. This code currently contains no tests, I do not want to go any
further until I
know this path is
agreed upon.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:19 p.m.
On 12/03/2010 04:13 AM, Guillaume Lerouge wrote:
Looks promising to me as well... Is there a way I could get a version to
test without having to build XWiki?
Guillaume
Hi,
On Fri, Dec 3, 2010 at 08:55, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
The versioning store is not written yet but that's about what I plan to do.
My plan is to use:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579~1.1.jpg
because the user might attach a file called 30579_1.jpg which would collide with 30579.jpg
(version
1) "~" will be escaped by URL encoding which happens to the file name which
ensures no collisions.
Caleb
On 12/03/2010 12:45 AM, Caleb James DeLisle
wrote:
Right now, where are all the versions of a given file stored and under which
name? Is there
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_1.jpg
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_2.jpg
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579_3.jpg
and so on?
If not, where are previous versions of the file stored? I now have a working model of attachment storage
in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it
simply by adding the .jar
file to the /lib/ dir and
changing the attachment store in the xwiki.cfg.
This introduces a 2 major changes to the storage direction which I want
to go
over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which
does a
job inside of a
transaction, it also provides hooks for rollback,
commit and complete
events. The underlying concept
is that code which is to run inside of a
transaction is passed as an
object to the storage engine
where the transaction is opened and it is run.
This will make the
exception catching generic for all
storage and Transaction is an interface
independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
Maybe you should make the start method final.
NOTE: I have TransactionRunnable as a nested
class while it is in
development and I intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a
document
called
xwiki:Main.WebHome will be stored in a file at
the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a
character
which is URL
invalid and thus insures that if nested spaces
are implemented, a
document called
xwiki:Main.WebHome.attachments will not cause a
collision.
The "attachments" directory is a directory dedicated to attachments for
the given document.
The "30579.jpg" directory under the
attachments directory is dedicated to
all information related to
that directory. This opens the possibility for
attachment history to be
stored along side the
attachment content.
WDYT?
Looks good to me, +1.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Caleb
PS. This code currently contains no tests, I do not want to go any
further until I
know this path is
agreed upon.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:24 a.m.
On Dec 2, 2010, at 11:45 PM, Caleb James DeLisle wrote:
I now have a working model of attachment storage in
the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
Sounds cool. Note that I haven't read the code.
This introduces a 2 major changes to the storage
direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I
intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
I don't understand why we need ~this. Why can't we count the number of directories
from the end?
..../attachments/<attachmentname>/<attachmentversion>
So to know the attachment name it's simply 2 "/" from the end.
WDYT?
Caleb
PS. This code currently contains no tests, I do not want to go any further until I know
this path is
agreed upon.
bad bad :)
Are you saying this wasn't TDD-developed? Oh my gaaawwwd.....
-Vincent
2:20 p.m.
On 12/03/2010 05:24 AM, Vincent Massol wrote:
On Dec 2, 2010, at 11:45 PM, Caleb James DeLisle wrote:
If we are never going to implement nested spaces then that plan would work fine. The
problem with
nested spaces comes when you have a nested space called "attachments" and then
you will have a
collision.
Caleb
I now have a working model of attachment storage
in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
Sounds cool. Note that I haven't read the code.
This introduces a 2 major changes to the storage
direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I
intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
I don't understand why we need ~this. Why can't we count the number of
directories from the end?
..../attachments/<attachmentname>/<attachmentversion>
So to know the attachment name it's simply 2 "/" from the end. WDYT?
Caleb
PS. This code currently contains no tests, I do not want to go any further until I know
this path is
agreed upon.
bad bad :)
Are you saying this wasn't TDD-developed? Oh my gaaawwwd.....
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:07 p.m.
On Dec 3, 2010, at 2:20 PM, Caleb James DeLisle wrote:
On 12/03/2010 05:24 AM, Vincent Massol wrote:
Why? I don't see any collision.
Thanks
-Vincent
On Dec 2, 2010, at 11:45 PM, Caleb James DeLisle wrote:
If we are never going to implement nested spaces then that plan would work fine. The
problem with
nested spaces comes when you have a nested space called "attachments" and then
you will have a
collision. I now have a working model of attachment storage
in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
Sounds cool. Note that I haven't read the code.
This introduces a 2 major changes to the storage
direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I
intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
I don't understand why we need ~this. Why can't we count the number of
directories from the end?
..../attachments/<attachmentname>/<attachmentversion>
So to know the attachment name it's simply 2 "/" from the end.
Caleb
>
>> WDYT?
>>
>> Caleb
>>
>>
>> PS. This code currently contains no tests, I do not want to go any further until
I know this path is
>> agreed upon.
>
> bad bad :)
>
> Are you saying this wasn't TDD-developed? Oh my gaaawwwd.....
>
> -Vincent
3:20 p.m.
On 12/03/2010 09:07 AM, Vincent Massol wrote:
On Dec 3, 2010, at 2:20 PM, Caleb James DeLisle wrote:
"..../attachments/<attachmentname>/<attachmentversion>"
You have a document called xwiki:Main.WebHome and you attach a file called myAttach.
That goes in xwiki/Main/WebHome/attachments/myAttach/1.0
Now you add a document called xwiki:Main.WebHome.attachments.myAttach.1\.0
and you attach a file called anotherAttach to this document.
That attachment would go in:
xwiki/Main/WebHome/attachments/myAttach/1.0/attachments/anotherAttach/1.0
xwiki/Main/WebHome/attachments/myAttach/1.0 already exists and it is not a directory.
Caleb
On 12/03/2010 05:24 AM, Vincent Massol wrote:
Why? I don't see any collision.
On Dec 2, 2010, at 11:45 PM, Caleb James DeLisle wrote:
If we are never going to implement nested spaces then that plan would work fine. The
problem with
nested spaces comes when you have a nested space called "attachments" and then
you will have a
collision. I now have a working model of attachment storage
in the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
Sounds cool. Note that I haven't read the code.
This introduces a 2 major changes to the storage
direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I
intend to move
it out when it becomes more mature.
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
The names are URL encoded for security. The directory ~this contains a character which is
URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
I don't understand why we need ~this. Why can't we count the number of
directories from the end?
..../attachments/<attachmentname>/<attachmentversion>
So to know the attachment name it's simply 2 "/" from the end.
Thanks
-Vincent
Caleb
>
>> WDYT?
>>
>> Caleb
>>
>>
>> PS. This code currently contains no tests, I do not want to go any further until
I know this path is
>> agreed upon.
>
> bad bad :)
>
> Are you saying this wasn't TDD-developed? Oh my gaaawwwd.....
>
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:11 p.m.
On 12/02/2010 11:45 PM, Caleb James DeLisle wrote:
I now have a working model of attachment storage in
the sandbox.
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
I can upload and download attachments with it simply by adding the .jar file to the /lib/
dir and
changing the attachment store in the xwiki.cfg.
This introduces a 2 major changes to the storage direction which I want to go over:
1. TransactionRunnable. This is a closure (like java.lang.Runnable) which does a job
inside of a
transaction, it also provides hooks for rollback, commit and complete events. The
underlying concept
is that code which is to run inside of a transaction is passed as an object to the
storage engine
where the transaction is opened and it is run. This will make the exception catching
generic for all
storage and Transaction is an interface independent of Hibernate or SQL.
See the bottom part of:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
NOTE: I have TransactionRunnable as a nested class while it is in development and I
intend to move
it out when it becomes more mature.
+0.5 (I need to take a closer look at this, but my initial feeling is
that this is a good approach).
2. Filesystem hierarchical storage: An attachment called 30579.jpg a document called
xwiki:Main.WebHome will be stored in a file at the path:
work/storage/xwiki/Main/WebHome/~this/attachments/30579.jpg/30579.jpg
+1 (I already talked abut this on IRC with Caleb).
The names are URL encoded for security. The directory
~this contains a character which is URL
invalid and thus insures that if nested spaces are implemented, a document called
xwiki:Main.WebHome.attachments will not cause a collision.
The "attachments" directory is a directory dedicated to attachments for the
given document.
The "30579.jpg" directory under the attachments directory is dedicated to all
information related to
that directory. This opens the possibility for attachment history to be stored along side
the
attachment content.
WDYT?
Caleb
PS. This code currently contains no tests, I do not want to go any further until I know
this path is
agreed upon.
This is bad. Tests should drive development, since they are the
specification of what needs to be done, and they are also the validation
that what was done is correct.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5086
days inactive
5087
days old
8 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol