10 Nov
2010
10 Nov
'10
4:02 p.m.
Caleb,
I share the thoughts of Guillaume: it's definitely something I wish to encourage and
that big platforms such as Curriki and i2geo would enjoy for scalability!
Is there any reason to use a varbinary instead of a simple string?
At least string would be easier to export and develop with.
paul
On 10 nov. 2010, at 10:02, Guillaume Lerouge wrote:
On Tue, Nov 9, 2010 at 21:08, Caleb James DeLisle
<calebdelisle(a)lavabit.com>wrote;wrote:
No opinions on this whatsoever? Should the lack
of support be taken as a
general -1? In this case I
will have to rethink how I can improve attachment storage as an entirely
separate drop in module.
This is unfortunate since rewriting will mean delays and inability to alter
the core will probably
mean hacks.
No, I rather think that the lack of answers comes from the high technical
level of the overall work to be done in this area combined with a general
lack of expertise on the developer's side with regard to what's the best
thing to do to improve the storage (else it would have been done already).
In short: you've got my support to make things better in this area by
whatever means you deem fit, although I'm of no help about practical
implementation details. Let's say this is my non-binding +1 ;-)
Guillaume
Caleb
On 11/05/2010 04:27 AM, Caleb James DeLisle wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi all,
In order to allow XWikiAttachment to reference data in multiple places,
we need
XWikiAttachment to
know the location of it's content.
XWikiAttachmentContent uses an id
which is identical to the
XWikiAttachment id meaning XWikiAttachmentContent
has no id of it's own,
only a foreign key which
points to the content.
To remedy this I propose the addition of a UUID hibernate UserType. This
type will
store a UUID as a
16 byte VARBINARY entry (little endian encoding)
in order to minimize the
size and database load.
Note: I discovered that a UUID type was added in a later version of
hibernate so
when we upgrade we
can decide whether to begin using their
implementation.
I would like to add the UUID type as the first class in a new module
xwiki-store
(in a submodule
called xwiki-store-hibernate).
I think the best approach is to add new database code to xwiki-store
slowly until
eventually the
storage drivers in the core are no longer used
thus "moving a mountain
one shovel full at a time".
The UUID implementation:
http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-store/xwiki-store-…
How it works:
Add this to the xwiki.hbm.xml where you want to add a UUID:
<property name="contentUUID"
type="org.xwiki.store.hibernate.types.UUIDToBinaryType">
<column name="contentuuid" />
</property>
(type can be mapped to a shorter name such as "UUID")
Add this to the bean class:
public UUID getContentUUID()
public void setContentUUID(final UUID contentUUID)
Hibernate takes care of the rest.
WDYT?
Caleb
_______________________________________________
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