I'm still thinking about this. The only thing I've come up with so far
is to enclose all the database updates in a subroutine, and put the code
from kohaversion.pl into updatedatabase.pl. That would make one less
file to edit. And if the few sub's at the end of updatedatabase.pl were
moved to th
I have an interesting idea about the system preference request in the
last point here.
Have the system preference editor create in the database a row for any
pref's it didn't find there. It would have to keep track of what the
default value should be for all pref's though.
With the new system pr
I've been assuming all this time, without stating the assumption, that
new database changes would only be appended to the list in
updatedatabase.pl. I thought that would guarantee the linearity that
you are talking about. Of course it is important to have this linearity
fro the reasons you have m
Hi,
2010/2/3 Joe Atzberger :
> On Tue, Feb 2, 2010 at 6:30 PM, Michael Hafen
> wrote:
> I realize I haven't been pushing code towards Koha for maybe half a year
> now, but I honestly don't think that DB revisions were a big enough problem
> to have us abandon the advantages of the current approac
On Tue, Feb 2, 2010 at 6:30 PM, Michael Hafen wrote:
> On Tue, 2010-02-02 at 16:50 -0500, Joe Atzberger wrote:
> > There is one great advantage of the current approach, and that is that
> > when a user says "we are on Koha version X", you know exactly what the
> > database state for that should be
Reply inline.
On Tue, 2010-02-02 at 16:50 -0500, Joe Atzberger wrote:
> There is one great advantage of the current approach, and that is that
> when a user says "we are on Koha version X", you know exactly what the
> database state for that should be. You know the tables, fields,
> constraints A
There is one great advantage of the current approach, and that is that when
a user says "we are on Koha version X", you know exactly what the database
state for that should be. You know the tables, fields, constraints AND the
codebase. To be clear, that means that you can *do development* specifi
> As release maintainer for 3.0 I **had to*** create and arrange db
> updates in a different order than master branch. Knowing wich db version
> you were on 3.00.01 and not 3.01 was really important, even though its
> management could have been improved. (Things that would add some tables
> and ma
> As release maintainer for 3.0 I **had to*** create and arrange db
> updates in a different order than master branch. Knowing wich db version
> you were on 3.00.01 and not 3.01 was really important, even though its
> management could have been improved. (Things that would add some tables
> and ma
Michael Hafen a écrit :
>>> My opinion is that the current system is not that bad. The
>>>
> dependency
>
>>> graph is linear, date ordered by version number last digits. It just
>>> becomes crazy when updates are ported from one branch to the other, HEAD
>>> to maintenance for example. A
Frederic Demians
> Those kind of things can be tricky and messy. Something like a
> dependency graph would be required, which is all but easy to implement.
> It has something to do with how patches are applied with git: [...]
I think a different way of handling database updates is a good idea
b
On Fri, 2010-01-29 at 05:46 +0100, LAURENT Henri-Damien wrote:
> Imagine we had a column activate in your table where an active update
> would HAVE to be done.
> We would be able to "check" that it has been done.
I think it could be easier than that. If your update is dependent on
another update
> > My opinion is that the current system is not that bad. The
dependency
> > graph is linear, date ordered by version number last digits. It just
> > becomes crazy when updates are ported from one branch to the other, HEAD
> > to maintenance for example. And there is (am I wrong?) to claim
> > 'co
Frederic Demians a écrit :
> Those kind of things can be tricky and messy.
Other idea : shouldn't we open a new position, named "database
consistency manager" or something like that ?
--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08
__
I think this idea has snowballed into something way more complex than
the original idea, which I still prefer.
> My opinion is that the current system is not that bad. The dependency
> graph is linear, date ordered by version number last digits. It just
> becomes crazy when updates are ported from
Those kind of things can be tricky and messy. Something like a
dependency graph would be required, which is all but easy to implement.
It has something to do with how patches are applied with git: order
matters. 'git log --graph --pretty-oneline' displays s a representation
of this order. Git m
Michael Hafen a écrit :
> Calling out to atomic files would be a good idea. It only partially
> alleviates merge conflicts though, because the reference to the file
> still have to appear in updatedatabase.pl. You would end up missing an
> entire update rather than potentially messing up part of
Calling out to atomic files would be a good idea. It only partially
alleviates merge conflicts though, because the reference to the file
still have to appear in updatedatabase.pl. You would end up missing an
entire update rather than potentially messing up part of an update with
a merge conflict.
Michael Hafen a écrit :
> Update order. I hadn't thought of that. That could be a big deal.
>
>
Well it could be important at some point :
you cannot update a field which doesnot exist.
And so on
> I'm already committed to writing it if it does get traction. I have a
> couple database upd
I would have to agree the patch order probably won't be an issue, as
each patch will still be added in the chronological order that it was
committed ( assuming every always adds to the end of the file as usual
).
Kyle
http://www.kylehall.info
Information Technology
Crawford County Federated Libra
Update order. I hadn't thought of that. That could be a big deal.
I'm already committed to writing it if it does get traction. I have a
couple database updates in my own branch that couldn't be in the the
updatedatabase.pl obviously. If this does get traction and we can
figure out the patch or
On Thu, Jan 28, 2010 at 1:04 PM, Kyle Hall wrote:
>> create a syspref (with TEXT, we have a lot of space).
>> Separate each patch applied with a comma :
>>
>> BibLibre-1,mhafenA,someoneElse,anotherone,BibLibre-2, ...
>>
>> need to check that a patch has been applied ? just =~ /BibLibre-1,/ if not
> create a syspref (with TEXT, we have a lot of space).
> Separate each patch applied with a comma :
>
> BibLibre-1,mhafenA,someoneElse,anotherone,BibLibre-2, ...
>
> need to check that a patch has been applied ? just =~ /BibLibre-1,/ if not
> applied, apply it, and add BibLibre-1, at the end of ap
Kyle Hall a écrit :
> The naming convention sounds very reasonable. Very java import styled.
> Very good idea.
>
> Now the big question is, can we get any traction for such a big
> change? Is there anyone else willing to comment on the possbility of
> this idea?
>
create a syspref (with TEXT, we
The naming convention sounds very reasonable. Very java import styled.
Very good idea.
Now the big question is, can we get any traction for such a big
change? Is there anyone else willing to comment on the possbility of
this idea?
Kyle
http://www.kylehall.info
Information Technology
Crawford Cou
Clearing the tracking table isn't necessary. I'm thinking 50 versions
down the road when the tracking table has some 500 strings. This makes
it a little harder to ensure a unique string for the update. And I
would rather the table stay small to be quicker to index and to take up
less space on th
I like this idea. I've had a number of problems with the current
system. If I understand correctly, we would need a database table to
track updates. It sounds like we would only need a single column that
would contain the title of the update, say "BugFix2235" for example.
The update script would th
Database updates using the updatedatabase.pl script. I'm thinking there
could be a better way, both for developers and the release maintainers.
The problem is that we have a sequential number controlling the updates.
This is working now, but I think there could be a better way. The
current metho
28 matches
Mail list logo
