Hello!
On Tuesday 15 December 2009 19:05:31 D. Richard Hipp wrote:
> Maintaining a fork of SQLite using Fossil is not difficult. A sketch
> of one solution can be found at http://www.sqlite.org/
> privatebranch.html and there is an updated version of that document
> at http://www.sqlite.org
> - Message from Alexey Pechnikov on Tue,
> 15 Dec 2009 22:14:07 +0300 -
>
> To:
>
> General Discussion of SQLite Database
>
> Subject:
>
> Re: [sqlite] Gauging interest in patches...
>
> Hello!
>
> On Tuesday 15 December 2009 19:17:31
Hello!
On Tuesday 15 December 2009 19:05:31 D. Richard Hipp wrote:
> Maintaining a fork of SQLite using Fossil is not difficult.
The are some problems of usage:
1. Then I use reverse proxy-server Fossil does not check
the existence of X-Forwarded-For header and does not ask
login/password. Yes,
Hello!
On Tuesday 15 December 2009 19:05:31 D. Richard Hipp wrote:
> Maintaining a fork of SQLite using Fossil is not difficult. A sketch
> of one solution can be found at http://www.sqlite.org/
> privatebranch.html and there is an updated version of that document
> at http://www.sqlite.org
Hello!
On Tuesday 15 December 2009 18:35:18 wcl...@gfs-hofheim.de wrote:
> I have made you a patch file for just the READONLY and ENFORCE table
> constraints.
Please send me the original patch. All features are interesting and I want
to test them.
> I think if I post the patch here it will get
Hello!
On Tuesday 15 December 2009 19:17:31 wcl...@gfs-hofheim.de wrote:
> Trying to attach a non-existent database as "readonly" will return the
> error "unable to open database file".
This message is not helpful becouse is used in other situations. Is it
possible to change it?
Best regards,
D. Richard Hipp wrote on 15/12/2009 17:05:31:
> (1) Have your patches been fully documented and have you generated
> automated test cases that provide 100% MC/DC and branch test
> coverage? I'm guessing not and yet those are requirements for new
> features in the core.
I believe they are full
Alexey Pechnikov wrote on 15/12/2009 15:15:42:
>> 3. ENFORCE constraint for table columns, for example: CREATE TABLE t(i
>> enforce integer, j enforce text). This optional constraint enforces
type
>> checking so that an entry must match the column type (i.e. integer,
real,
>> numeric, text,
On Dec 15, 2009, at 8:26 AM, wcl...@gfs-hofheim.de wrote:
>
> This is a quick email just to gauge interest in a number of patches
> I've
> created for Sqlite over the last year or so.
Your best bet would probably be to clone the SQLite Fossil repository
and publish your own private branch as
John Brooks wrote on 15/12/2009 15:13:05:
> I love the idea of READONLY and ENFORCE. I would certainly make use of
> those in amalgamation form. What license do you put these under?
>
> You should really publish these all somewhere, there are some great
> features. Good work.
Thank you.
I have m
Hello!
On Tuesday 15 December 2009 16:26:00 wcl...@gfs-hofheim.de wrote:
> 3. ENFORCE constraint for table columns, for example: CREATE TABLE t(i
> enforce integer, j enforce text). This optional constraint enforces type
> checking so that an entry must match the column type (i.e. integer, real
I love the idea of READONLY and ENFORCE. I would certainly make use of
those in amalgamation form. What license do you put these under?
You should really publish these all somewhere, there are some great
features. Good work.
- John Brooks
On Tue, Dec 15, 2009 at 6:26 AM, wrote:
> Hi all,
>
>
Hi all,
This is a quick email just to gauge interest in a number of patches I've
created for Sqlite over the last year or so. What I want to know is
whether anyone would like me to post one or more of these patches here? I
have thought about posting to http://www.sqlite.org/contrib but since
13 matches
Mail list logo
