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.
Caleb
On 11/05/2010 04:27 AM, Caleb James DeLisle wrote:
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