On Thu, Feb 10, 2011 at 15:53, Caleb James DeLisle <[email protected]> wrote:
You make a good point about not touching anything. I agree totally about not modifying the behavior of storage without a configuration switch but to not modify the code at all has a few other consequences.
1. xwiki-core is serving a dual purpose, it is the client of all the services provided by the modules and it is the grave yard for dead and deprecated code. I would like the idea much better if we could usher the dead code from xwiki-core to another module so that core of the application is not the dead code cemetery.
Note that there is xwiki-legacy project and aspect in xwiki-core to remove deprecated code from project or java files we want to cleanup.
2. The point about custom storage implementations could be applied to any old code, any line we change might be breaking someone who depends on it, this is especially true because groovy allows access to private fields and methods without even a warning. From the community standpoint, people who make patch sets and keep them secret are harming the community by keeping their (potentially very good) modifications to themselves, this is the same discussion which goes on with the Linux kernel and closed source modules, I agree with Linus here that although we should not try to stop this practice we should also not protect it by preserving internal APIs.
The approach I have thus far taken has been to remove unused code, implement APIs externally, and move things over one at a time. This gives us results right away and makes xwiki-core less bloated but it leaves behind sub-optimal APIs which still need to be rewritten again and introduces more bugs since every interface is at some point reimplemented.
Your method (as I understand it) is to rewrite things in large chunks but (at least with rendering) never to break the old API. Reimplementing storage this way would mean we need the thing to store (XWikiDocument) and the objects and properties which amounts to a total rewrite of core before the first result comes in.
If we are to keep deprecated code such as rendering1.0 (forever?) I think we need to move it out of the core where it confuses attempts to fix core bugs.
Caleb
On 02/09/2011 09:21 AM, Vincent Massol wrote:
+0 for the idea but I don't know that part of the code enough to know what problems this is going to cause (custom storage implementations out there, etc).
Personally I'd have preferred to not touch a single bit at any existing storage interfaces and instead introduce new storage APIs in the new xwiki-store module and have a flag to direct to the old or new implementations. This is basically the strategy we followed with the new rendering engine and that has allowed us to keep 100% backward compat for the XWiki 1.0 syntax.
Thanks -Vincent
On Feb 9, 2011, at 2:20 PM, Caleb James DeLisle wrote:
I would like to propose another round of storage deprecations, the goal of these is to remove and decrease visibility of code in order to simplify storage and move as much as possible over from API to implementation details. I am proposing deprecation of each of the following, after 2 releases this may be revisited and they may be removed or altered. The following are changes I have made locally and found xwiki-core does compile and test with those changes. For now I propose adding deprecation comments and annotations to each class or method.
WDYT?
Caleb
XWikiAttachmentStoreInterface.java saveAttachmentContent(XWikiAttachment attachment, XWikiContext context, boolean bTransaction) remove
cleanUp(XWikiContext context) remove
XWikiBatcher.java remove entirely
XWikiBatcherFactory.java remove entirely
XWikiBatcherStats.java remove entirely
XWikiDefaultStore.java remove entirely
XWikiHibernateBaseStore.java getDatabaseProductName(XWikiContext context) public --> protected
shutdownHibernate(XWikiContext context) remove
updateSchema(XWikiContext context) public --> private
getSchemaFromWikiName(String wikiName, DatabaseProduct databaseProduct, XWikiContext context) protected --> private
getSchemaFromWikiName(XWikiContext context) protected --> private
getSchemaUpdateScript(Configuration config, XWikiContext context) public --> private
updateSchema(String[] createSQL, XWikiContext context) public --> private
updateSchema(BaseClass bclass, XWikiContext context) remove
isVirtual(XWikiContext context) public --> protected
beginTransaction(SessionFactory sfactory, XWikiContext context) public --> protected
beginTransaction(SessionFactory sfactory, boolean withTransaction, XWikiContext context) public --> protected
endTransaction(XWikiContext context, boolean commit, boolean withTransaction) public --> protected
execute(XWikiContext context, boolean bTransaction, boolean doCommit, HibernateCallback<T> cb) public --> private
XWikiHibernateStore.java getContent(XWikiDocument doc, StringBuffer buf) remove
public List search(Query query, int nb, int start, XWikiContext context) remove
injectCustomMappingsInSessionFactory(BaseClass bclass, XWikiContext context) public --> private
injectCustomMappingsInSessionFactory(XWikiContext context) public --> private
XWikiHibernateVersioningStore.java loadAllRCSNodeInfo(XWikiContext context, final long id, boolean bTransaction) protected --> private
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne