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 > <[email protected]>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: >>> 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-hibernate/src/main/java/org/xwiki/store/hibernate/types/UUIDToBinaryType.java >>> >>> 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 >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
