[xwiki-devs] [proposal] Deprecate XWikiAttachmentArchive#getArchive() and setArchive() and remove and make private deprecated methods in XHS
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. 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 I would like to remove the following methods entirely as they are also deprecated and are not used at all: getBatcherStats resetBatcherStats deleteXWikiClass saveXWikiClassProperty WDYT? Caleb
Hi Caleb, On Dec 16, 2010, at 6:42 AM, Caleb James DeLisle wrote:
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). 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. </future design> Have you been working on this too or do you plan to? Thanks -Vincent
On 12/16/2010 03:01 AM, Vincent Massol wrote:
Hi Caleb,
On Dec 16, 2010, at 6:42 AM, Caleb James DeLisle wrote:
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. 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.
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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
Caleb James DeLisle -
Vincent Massol