Op 26-11-11 11:15, BWS Johnson schreef:
> Any reason not to do it at logoff in the background?
People may not logoff, also they may not see errors/warnings if they go
away immediately.
That said, if you do it on the login screen, which is where the logoff
screen takes you, it's really the sam
Hello,
I just have submitted on bug 7167 3 patches that are working as
expected. You can also get a document with screenshots at
https://depot.biblibre.com/ppoulain/updatedb%20for%203.8.odt (can't
upload it on bugzilla, it's too large: 1.6MB, vs a 1.0MB limit)
(Note that the "testing patch" is her
Kia ora!
> Maybe a middle solution would be to have do a check on the login page
> only (or on mainpage.pl ?). As it's mandatory to log-in on the staff
> interface, that seems fair.
Any reason not to do it at logoff in the background?
Cheers,
Brooke
___
Ian Walls [...]
> We were discussing the following at hackfest:
:-( but thank you for documenting it now.
[...]
> A YAML file, edited by the RM only, that assigns those update files to a
> specific database revision number. This gives us a quick and ordered means
> of determining what has been
Op 25-11-11 04:20, Paul Poulain schreef:
> In a few months, we will have 40 different files. And hashing/CRCing
> 40 files is not negligible.
File_names_, not files. And CRCing on string of 40 filenames is pretty
negligible.
I just want to avoid people trucking along with new code on an old
datab
On Thu, Nov 24, 2011 at 10:20 AM, Paul Poulain
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 24/11/2011 13:22, Robin Sheat a écrit :
>> Op 25-11-11 00:49, Ian Walls schreef:
>>> I do like the idea of hashes... but looking at it, we'd
>>> essentially be mimicking the data structur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 24/11/2011 13:22, Robin Sheat a écrit :
> Op 25-11-11 00:49, Ian Walls schreef:
>> I do like the idea of hashes... but looking at it, we'd
>> essentially be mimicking the data structure we already have with
>> Git commits. Plus, readability goes do
Op 25-11-11 00:49, Ian Walls schreef:
> I do like the idea of hashes... but looking at it, we'd essentially be
> mimicking the data structure we already have with Git commits. Plus,
> readability goes down.
Is readability an issue here? I was thinking a process like:
1) on each page (and this'll
We were discussing the following at hackfest:
a directory of atomic database updates. While my intent was for .pl files,
we could adapt to include .sql, as well. I just really like the idea of a
CHECK/DO/UNDO interface
A YAML file, edited by the RM only, that assigns those update files to a
spe
2011/11/23 Jared Camins-Esakov :
> You know what this thread is missing? 2 cents from yours truly!
>
>>
>> Perhaps a quick hash/CRC of the filenames of the patches that have been
>> applied? Should be quick to generated and test, and will tell us
>> immediately if we need to run again.
>
> +1 from
On 2011-11-21, at 8:52 PM, Paul Poulain wrote:
>
> Le 20/11/2011 01:09, Mason James a écrit :
>> now.. how could an .SQL only solution achieve this? - its
>> impossible, right?
>>
>> - using .pl patches, with a *combination* of perl and sql, would
>> allow us the best of both options - using .s
Robin Sheat
> Perhaps a quick hash/CRC of the filenames of the patches that have been
> applied? Should be quick to generated and test, and will tell us
> immediately if we need to run again.
That was another idea, but I thought a sufficient hash would be a very
long version number from the start
>> I would say that we do not need that check everywhere, but I would
>> keep it at login time.
> This idea could be investigated for someone that log-in with admin
> permission, for example.
> Does others think it's a must-have ? Here at BibLibre, most of us
> think checking the database update
You know what this thread is missing? 2 cents from yours truly!
> Perhaps a quick hash/CRC of the filenames of the patches that have been
> applied? Should be quick to generated and test, and will tell us
> immediately if we need to run again.
>
+1 from me
My vote is for using a hash for identi
MJ Ray schreef op wo 23-11-2011 om 22:46 [+]:
> Can anyone do better or should we junk that idea?
I tend to agree with you here, I think.
Perhaps a quick hash/CRC of the filenames of the patches that have been
applied? Should be quick to generated and test, and will tell us
immediately if we
Paul Poulain
> Le 23/11/2011 17:02, Marcel de Rooy a écrit :
> > I would say that we do not need that check everywhere, but I would
> > keep it at login time.
> This idea could be investigated for someone that log-in with admin
> permission, for example.
> Does others think it's a must-have ? Here
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 23/11/2011 17:02, Marcel de Rooy a écrit :
> Quote from Bugzilla #7167 Here is how it works: * each database
> update is stored in a numbered file, in
> installer/data/mysql/versions * database updates can be .sql or .pl
> files. 2 skeletons are pro
n...@lists.koha-community.org] namens Paul Poulain
[paul.poul...@biblibre.com]
Verzonden: maandag 21 november 2011 8:52
Aan: koha-devel@lists.koha-community.org
Onderwerp: Re: [Koha-devel] Update database changes proposal [IMPORTANT]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 20/11/2011 01:09
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 20/11/2011 01:09, Mason James a écrit :
> now.. how could an .SQL only solution achieve this? - its
> impossible, right?
>
> - using .pl patches, with a *combination* of perl and sql, would
> allow us the best of both options - using .sql patches a
On 2011-11-19, at 8:18 AM, MJ Ray wrote:
> Mason James
>>
>> i think if we want to do Ian's suggested check/apply/roll-back idea
>> for DB changes, we will indeed need to use .pl files not .sql files
>> for new patches
>
> I'm not sure about that either. Surely it could be done by setting
> S
Mason James
> On 2011-11-18, at 5:43 AM, Paul Poulain wrote:
> > Le 09/11/2011 18:54, Mason James a écrit :
> >> do other people agree?
> > not at all ! Sometimes (not very often, but not rarely either), more
> > complex calculations must be made, like for
> >
> > For example:
> > depending on yo
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 h
On 2011-11-18, at 5:43 AM, Paul Poulain wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 09/11/2011 18:54, Mason James a écrit :
>> do other people agree?
> not at all ! Sometimes (not very often, but not rarely either), more
> complex calculations must be made, like for
>
> For
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 09/11/2011 18:54, Mason James a écrit :
> do other people agree?
not at all ! Sometimes (not very often, but not rarely either), more
complex calculations must be made, like for
For example:
depending on your marcflavour you do something or somethi
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.
Work is on BibLibre git repository
giit://git.biblibre.com/koha_biblibre.giton branch solr/ft/updatedb
The
Ian Walls
> I'd like to see the atomic update files continue to be perl, not SQL. SQL
> is often sufficient to do an update, but not always, particular if we're
> swapping out one implementation of a feature for a more generic one.
Most things can be done with some combination of ALTER, UPDATE a
2011/11/10 Ian Walls :
> Undo: undoes the change to the database, allowing rollback to previous code
> states (this would be a new function)
This could get very tricky if the update also made changes to existing
data. It seems there would be the need for a sort of "undelete"
table/file/foo.
Othe
I'd like to see the atomic update files continue to be perl, not SQL. SQL
is often sufficient to do an update, but not always, particular if we're
swapping out one implementation of a feature for a more generic one.
Also, I'd like to see 3 different subroutines/functions for each atomic
update:
On 2011-11-8, at 3:42 AM, MJ Ray wrote:
> Paul Poulain
>> Let's say Limoges library has sponsored stuff that has resulted in
>> atomicupdate/limogeupdate.pl
> [...]
>> Does anyone see a problem with this new updatedatabase procedure ?
>
> The only problem that I can see is that we should encour
Paul Poulain
> Let's say Limoges library has sponsored stuff that has resulted in
> atomicupdate/limogeupdate.pl
[...]
> Does anyone see a problem with this new updatedatabase procedure ?
The only problem that I can see is that we should encourage
updates to be .sql not .pl files.
Other than tha
Le 05/11/2011 15:02, Ian Walls a écrit :
Another way to say it:
No patches will be accepted with edits to the YAML file.
also
If you edit your local copy of the YAML file, do not assign a number;
use localchange instead. Otherwise you will encounter problems.
-Ian
On Sat, Nov 5, 2011 at
Another way to say it:
No patches will be accepted with edits to the YAML file.
also
If you edit your local copy of the YAML file, do not assign a number; use
localchange instead. Otherwise you will encounter problems.
-Ian
On Sat, Nov 5, 2011 at 4:35 AM, Paul Poulain wrote:
> Le 05/11/2011
Le 05/11/2011 08:32, Julian Maurice a écrit :
> It seems to be a great evolution, but there is something which I think I
> don't understand:
>> * there won't be any conflict anymore of a patch applied and your .
>> file not applying anymore, needing a rebase
> Ok there will be no more conflicts
It seems to be a great evolution, but there is something which I think I
don't understand:
* there won't be any conflict anymore of a patch applied and your .
file not applying anymore, needing a rebase
Ok there will be no more conflicts in the updatedatabase.pl file, but
what about the YAML
For my part, I'm very excited about this change. I think we're going to
have a much easier time of submitting database changes this way. There
will be a learning curve for folks used to doing it the old way, but like
the change to using a common systempreferences.sql instead of one for each
langu
Hello,
During the hackfest in Mumbaï, 5 of us had a brainstorming about
database changes to try to improve it.
Here are the goals:
* must result in patches being easier to test by testers (to sign-off)
* must result in less conflict when trying to apply a patch with a DB
update when another patch
36 matches
Mail list logo
