Le 12/11/2011 13:00, Jonathan Druart a écrit :
Hi all ! I have already developed a new version of updatedatabase. It's not totally validated yet but in order to avoid parallels initiatives, let me explain you what I have already done. I just took one hour with Jonathan, that shows me what he did. It's already live for many of our customers, and I was not aware of this... more communication needed inside BibLibre :\
So, here is how it works: * each patch is stored in a file in a specific directory. It can be .pl or .sql, both are adressed * there is a new page on admin page, that displays, for each patch: - if it has been applied or no - the result, either failed or OK. If failed, the error is also available. You can decide to "force OK" a given patch to ignore the problem On this page, you can also apply all pending patches and/or apply them one by one. This is completly "delinearized" Those 2 points are what we have built during hackfest, but there are some differences: * there is no more automatic control of update needed. That's intended: when you update, you'll now have to go to admin/update page. This sounds quite logic to me: it's delinearized, so checking what has been applied/must be applied on everypage will be much too CPU consuming * patch numbering = in this patch, patches still have a number, thus they can be applied in order. but, as it's not linear, they can also be applied in non-linear order How does it work internally ? A table is added, that contains all applied patches, with the logging of the result. It also contains a md5sum of the applied patches, to detect a duplicate number-but-not-the-same Jonathan has sent me the patch, I'll test & submit it soon. It relies on jquery datatable, so the patch will require bug 6836 to be applied first. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08