That is kind of the line I was thinking of going.  I don't want to rely on
MD5 as an ID, as by chance I might get the same numbers back, especially if
I revert back to an already bit-exact existing schema.  (For instance, I do
a schema change, apply the update, but then find I have to revert to the
previous version of the schema then reapply).  As a test for differences
between previous version and current, that'd probably work, yes, and
probably would use it, but I don't think I'd store the MD5 result.  I'd use
the result from two queries (One against previous, the other against
current) and make the decision from there.

Unfortunately I'm using the amalgamation DLL right now, and based on the
code you've highlighted, I don't think that code gets included.  Since I'm
not using C, I'd have to rebuild the Amalagamation to get my DLL, which
isn't a huge deal, but that means I've just introduced another dependency,
which is something I'd like to avoid.

Is there a way that I can get your sub-query (Reordered to have tables,
then indexes, then views) to come out as one row?  I can then have the
application just do an easy string comparison, AND have a method to include
the resource string to create a new DB (FILE>NEW) in one go.

On Thu, Sep 8, 2016 at 10:16 AM, Richard Hipp <d...@sqlite.org> wrote:

> On 9/8/16, Stephen Chrzanowski <pontia...@gmail.com> wrote:
> >
> > However, the rabbit I was hoping to pull out of the hat was that the
> change
> > in version numbers be done automatically when I make a change in the 3rd
> > party DB management tool.
>
> Perhaps make your application schema-version number a hash of the SQL
> for the schema, like this:
>
>    SELECT md5sum(sql) FROM (
>       SELECT sql FROM sqlite_master
>        WHERE sql IS NOT NULL
>        ORDER BY sql
>    );
>
> You will need to add the md5sum() aggregate function yourself.  A
> sample implementation can be found in the SQLite source tree (used for
> testing) here: https://www.sqlite.org/src/artifact/bdae822f2?ln=3894-3932
>
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to