CAcert Code Development list.

[Jan Dittberner <jandd AT cacert.org>]

Am Sun, Aug 15, 2021 at 08:39:42PM +0000 schrieb Brian:
> On Sat, Aug 14, 2021 at 02:43:13PM +0200, Bernhard Fr??hlich wrote:
> > Hmm, Jan was a bit faster, I have now placed a "clean" database dump (no
> > user data included) at 
> > https://test.cacert.org/testserver_dbstructure.sql.gz
> >
> > Brian, maybe you could compare that script with Jan's version and tell us
> > what worked best for you, so it can be added to the WiKi documentation.
> >
> > Of course, other feedback is also welcome. :-)
> >
> > Kind regards
> > Ted
> 
> 
> Thank you both.  Test-building both showed a one-table difference
> between them.  If I remember correctly, Jan's had an extra table named
> "temp."

The temp table might be a leftover from the initial import. I came to the
schema description/migrations by taking the database from the test system
and comparing it with the migration scripts in the cacert-devel repo (which
missed the initial state of the database).

My goal was to be able to rebuild a database from scratch and from my
professional experience this only works well if you have a series of
migration scripts that is in version control together with the corresponding
code.

We currently have a few scripts but in the long term we should use proper
tooling for this. In Java based systems Flyway or LiquiBase are valid
choices for this. Python has several implementations like Alembic or the
Django migrations support. The Go community came up with golang-migrate that
I use in the motion system code [1]. I assume there may be similar solutions
for PHP if we should decide to continue using PHP for a while.

[1] https://git.cacert.org/cacert-boardvoting.git/tree/

> I am planning on creating perhaps three or four sample users, and then
> doing a dump of that one and sending it back to you for development and
> test work by other developers.  In other words, quick and easy setup
> when we are working on code.

A migration script that applies the necessary SQL statements would be even
more helpful :-)

> Speaking of code, boy did I make a mistake!  I will double check, but I
> think that I created a new branch from "release."
> 
> Unfortunately, it has "short open tags," ( <? instead of <?php ) and
> also "auto_prepend_file" in the .htaccess file, which does not work.
> Apparently, according to the documentation, that should work in a
> php.ini file, not in .htaccess.
> 
> What branch do you recommend that I use as the base of my work?
> 
> I can set the "short open tag" flag in my configuration to get around that
> problem, unless you want me to change all of the code to the "proper"
> value.

The PHP documentation advises against short open tags [2] but we have them
all over the place. I decided against replacing all occurences in my pull
request [3] for the mysqli change to not introduce more noise for the
reviewer(s).

[2] https://www.php.net/manual/en/language.basic-syntax.phptags.php
[3] https://github.com/CAcertOrg/cacert-devel/pull/21

I would base new work on my replace_deprecated_mysql_api [4] branch, because
I hope that this will be merged, hopefully soon :-)

@Ted What do you recommend?

[4] https://github.com/jandd/cacert-devel/tree/replace_deprecated_mysql_api


Kind regards
Jan

-- 
Jan Dittberner - CAcert Infrastructure Team Lead
Software Architect, Debian Developer
GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10
         B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
https://jan.dittberner.info/

Attachment: smime.p7s
Description: S/MIME cryptographic signature