I've solved these two (in my case sqlite3_busy_timeout isn't necessary and can just be removed, sqlite4_result_blob and sqlite4_result_text now take a xDel argument that can just be zeroed out, and sqlite4_create_collation now takes a callback to generate keys for the k/v storage engine that AFACT can be NULL'd for my use case but YMMV).
Now I believe I've stumbled on a bug in the amalgamation builder for sqlite4. When I generate the amalgamation for sqlite3 it includes fts3, and compiles any everyone's happy. When I generate the amalgamation for sqlite4 as of fde11ff78c433d66 it generates but fails to compile because it has a #include "fts3.h" line (and of course fts3.h isn't present in the project including the amalgamation). Am I just compiling this wrong or is it a build bug? On Tuesday, 23 April, 2013 at 09:18, David King wrote: > I'm experimenting with sqlite4 by porting an application that currently runs > sqlite3. I'm following the surprisingly straight-forward instructions at > http://sqlite.org/src4/doc/trunk/www/porting.wiki > > I see that sqlite4 no longer provides sqlite4_busy_timeout, is there an > equivalent that I should be using? If not, what's the preferred strategy here > now? > > Also these appear to take different numbers of arguments than they used to, > but aren't listed in that doc as needing to take a sqlite4_env*. Should they > be added to that list or is there a different change? > > sqlite4_result_blob > sqlite4_result_text > sqlite4_create_collation > > I realise that sqlite4 isn't production quality (this is just a toy that I'm > porting) and I'm happy to just help update docs where possible > > Thanks! > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org (mailto:sqlite-users@sqlite.org) > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
