Re: [UDD] How to properly maintain code in sql dir
On 17/05/13 at 11:20 +0200, Andreas Tille wrote:
> 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.
Yes, do you want to investigate how this can be done?
> 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?
Yes.
> Kind regards
>
> Andreas.
>
> PS: Perhaps we should add your short explanation to the README file.
Yes.
Lucas
Reply to: