17 Dec
2010
17 Dec
'10
6:36 a.m.
On 12/16/2010 03:01 AM, Vincent Massol wrote:
I favor evolution over revolution not only for the obvious reason that it is available
"now" but
because it allows changes to be tested immedietly. God forbid we invest in 20k lines of
code and
when finished we find it "looked good on paper" but simply does not work.
Hi Caleb,
On Dec 16, 2010, at 6:42 AM, Caleb James DeLisle wrote:
These are
only used by Hibernate and the packaging plugin. They are for serializing the attachment
archive as a byte array so it can be stored or exported. Since the filesystem
implementation will be
storing each attachment as a separate file, there is no analog. I believe this is
sufficiently
internal that we need not offer an upgrade path.
I would like to deprecate the following methods
because they insert and remove content which is
dependent on JRCS for parsing and generation:
XWikiAttachmentArchive#getArchive()
XWikiAttachmentArchive#getArchive(XWikiContext)
XWikiAttachmentArchive#setArchive(byte[])
These are not easily removed because they are needed for the packaging plugin but I think
we should
move away from that means of import/export as it contains code (including JRCS) which is
memory
inefficient.
+1 but if you deprecate you also need to explain by what it is replaced. Also in the 3.0 cycle, I would like to make
private the following methods from XWikiHibernateStore
as they are not used externally and are currently deprecated:
loadXWikiProperty
saveXWikiClass
loadXWikiClass
loadAttachmentList
saveAttachmentList
saveAttachment
injectCustomMappingsInSessionFactory
injectInSessionFactory
isValidCustomMapping
+0, I don't know enough the impact so my +0 is an ok in principle if it doesn't
break anything known.
I would like to remove the following methods
entirely as they are also deprecated and are not used
at all:
getBatcherStats
resetBatcherStats
deleteXWikiClass
saveXWikiClassProperty
Same as above:
+0, I don't know enough the impact so my +0 is an ok in principle if it doesn't
break anything known.
<future design>
I see you're going the evolution way rather than the revolution way. This is good to
make progress. In some not too far future I'd like that we
introduce a new xwiki-storage module with clean interface and based on components. The
Model classes (Document, Wiki, Space, etc) would have the calls to save/load/update/delete
and would call this storage module to perform the actual storage actions. This module
would offer generic interfaces and an implementation based on Hibernate (in a separate
xwiki-storage-hibernate module) and allow to have other implementations (JCR, etc).
I am also envisioning a new storage engine based on the TransactionRunnable class
which is currently
housed inside of FilesystemAttachmentStore. However, I want to experience the challenges
of using
TransactionRunnable in the real world before I start proposing any interfaces which use
it.
Note: I had wondered for a long time if we should use directly the JCR api instead of
having our own storage API (since JCR provides one) but in the end I think it's better
to have our own since it doesn't tie us to JCR and since JCR is not a massive adoption
success it's probably safest.
+1
Caleb
</future design>
Have you been working on this too or do you plan to?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs