Re: [UDD] How to properly maintain code in sql dir
Hi Lucas,
On Fri, May 17, 2013 at 10:21:46AM +0200, Lucas Nussbaum wrote:
> >
> > Currently I want to inject two things. One would be something like
> >
> > $ git diff
> > diff --git a/sql/upgrade.sql b/sql/upgrade.sql
> > index 271cf35..9bf596a 100644
> > --- a/sql/upgrade.sql
> > +++ b/sql/upgrade.sql
> > @@ -87,9 +87,15 @@ INSERT INTO releases VALUES ( 'squeeze-proposed-updates', NULL, 602 );
> > INSERT INTO releases VALUES ( 'wheezy', NULL, 700 );
> > INSERT INTO releases VALUES ( 'wheezy-security', NULL, 701 );
> > INSERT INTO releases VALUES ( 'wheezy-proposed-updates', NULL, 702 );
> > +INSERT INTO releases VALUES ( 'jessie', NULL, 800 );
> > +INSERT INTO releases VALUES ( 'jessie-security', NULL, 801 );
> > +INSERT INTO releases VALUES ( 'jessie-proposed-updates', NULL, 802 );
> > INSERT INTO releases VALUES ( 'sid', NULL, 100000 );
> > INSERT INTO releases VALUES ( 'experimental', NULL, 0 ); /* this pseudo releases does not fit any order and it is not higher than unstable */
> >
> > +UPDATE releases SET releasedate = '2011-02-06' WHERE release like 'squeeze%' ;
> > +UPDATE releases SET releasedate = '2013-05-05' WHERE release like 'wheezy%' ;
> > +
> > GRANT SELECT ON releases TO PUBLIC ;
> >
> >
> > Besides that I did not really understood the concept behind setup.sql
> > and upgrade.sql I wonder whether we should start using some sql.d/
> > like mechanism were you can drop sql code like
> >
> > sql.d/01_create_new_table.sql
> > sql.d/02_create_some_function.sql
> > sql.d/03_another_new_table.sql
> > sql.d/04_update_some_data.sql
> > etc.
> >
> > IMHO this would make development of new stuff more transparent.
>
> What would be the support tool that would understand this structure? How
> does it know which files were already executed?
I was not thinking of a tool in the first place (even if some shell
script could easily run the code in the same manner as setup.sql). I
was thinking more in the direction that it can be easier understand /
maintained because there are different people working on quite different
stuff in UDD and you could more easily test a separate file and just
copy it over. I do not say that the gain is very large compared to the
current approach - just an idea.
> The current way is:
> setup.sql contains the code to generate a pristine UDD db from scratch.
> upgrade.sql lists the command needed to upgrade a running UDD db. You
> can't run it, but you can copy-paste from it.
I think it would make some sense to be able to run it. Moreover: How
to decide whether the initialisation of the release table belongs to
setup.sql or to upgrade.sql?
> Under the current scheme, there should be no other files, so all your
> SQL code should go into setup.sql and upgrade.sql.
So I'm tempted to move the additional code from blends.sql into
setup.sql and run the code manually. Is this correct?
Kind regards
Andreas.
PS: Perhaps we should add your short explanation to the README file.
--
http://fam-tille.de
Reply to: