[sqlite] SQLite version 3.8.12 enters testing

[Zsbán Ambrus]

On Wed, Oct 7, 2015 at 9:42 PM, Richard Hipp  wrote:
> On 10/7/15, Zsb?n Ambrus  wrote:
> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

Thanks, that's much better.  The
"http://sqlite.org/draft/expridx.html; documentation tells all I
wanted to know.  However, it seems you forgot to link that
documentation from "http://sqlite.org/draft/docs.html; .  It should
probably be linked from under the heading "SQLite Features and
Extensions".

There is one apparent inconsistency I was wondering about.  For a
partial index, the WHERE clause of the index cannot contain functions;
whereas for an index on an expression, the expression can contain
deterministic functions.  What is the explanation of this difference?
Is it only historical, because the deterministic functions flag is a
new addition?

Ambrus

[sqlite] SQLite version 3.8.12 enters testing

[Dominique Devienne]

On Wed, Oct 7, 2015 at 11:01 PM, R.Smith  wrote:

> [...] (Brilliant release btw, thanks)
>

+1


> [...] This definitely feels like a 3.9 release rather than a 3.8.12. I
> mean it introduces functionality that a 3.8.11 engine won't be able to
> comprehend - and not just one obscure item either.
>

That alone warrants a 3.9 IMHO. Totally agree with Ryan.

And I think his point that any release that introduces a new feature, which
if used, makes prior version not being able to use the DB, a good rule of
thumb to decide whether to bump MINOR or not.

FWIW. My $0.02. Etc... :) --DD

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

On 10/8/15, Zsb?n Ambrus  wrote:
>
> There is one apparent inconsistency I was wondering about.  For a
> partial index, the WHERE clause of the index cannot contain functions;
> whereas for an index on an expression, the expression can contain
> deterministic functions.  What is the explanation of this difference?
> Is it only historical, because the deterministic functions flag is a
> new addition?
>

It is historical.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLite version 3.8.12 enters testing

[R.Smith]

Some notes on 3.8.12: (Brilliant release btw, thanks)

I've been following the thread about the version numbering, and at first 
thought the OP was a little over-enthusiastic about increasing version 
numbers prematurely, but then after reading the release notes, I have to 
agree to some extent - That is - I am not sure we should be changing the 
way SQLite is versioned altogether, but maybe a bit more prolific in the 
release versions? This definitely feels like a 3.9 release rather than a 
3.8.12. I mean it introduces functionality that a 3.8.11 engine won't be 
able to comprehend - and not just one obscure item either.



The Indexed expressions document 
(https://www.sqlite.org/draft/expridx.html) notes that the expression 
must be exactly reproduced in the query to make use of it (i.e. exactly 
as it was defined in the CREATE INDEX statement).
It goes on to note that "exactly" means syntactically equivalent (not 
mathematically etc.), which is great, and that whitespace does not 
matter. What about Capitalization and quotation?

i.e. - for this schema:

i.e. - for this schema:
CREATE TABLE t2(x,y,z);
CREATE INDEX t2xy ON t2(x+y);

Would these all be equivalent?

SELECT * FROM t2 WHERE X+y=22;
SELECT * FROM t2 WHERE "x" + "y" = 22;
SELECT * FROM t2 WHERE "x" + Y = 22;


Whatever the answer, may it be added to the documentation please? (A 
short example like the above would suffice I think).

-

Documentation error in the Restrictions section (typo):
"2. Expressions in CREATE INDEX *statmeent* may contain function calls, 
but only to functions whose output is always determined completely by 
its..."

--

Documentation error in the Release notes (pluralization):
"Enhance the dbstat virtual table 
 so that it can be used as *a 
table-valued functions 
* where the argument is..."


Thanks,
Ryan

[sqlite] SQLite version 3.8.12 enters testing

[Simon Slavin]

On 7 Oct 2015, at 8:42pm, Richard Hipp  wrote:

> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

I tentatively suggest that modifications be made to the text describing



and



.  However it may be that such changes would just lengthen the explanation 
without adding anything useful, and that any programmer who tries out those 
PRAGMAs with the new indexes won't have any trouble understanding what they see.

It also might be useful to produce a -2 in the second output column for 
index_xinfo, for columns which are calculations.

I wonder what happens if an index is defined which uses an application-defined 
functions, and a later attempt is made to use the database without that 
function defined.  I can see an argument for returning an error when any 
relevant SELECT is attempted.  But I can also see an argument for returning an 
error only when an attempt is made to INSERT or UPDATE into the indexed table.

Simon.

[sqlite] SQLite version 3.8.12 enters testing

[Peter Aronson]

Currently if you have a check constraint with a user-defined function that is 
not defined in the current environment, you can not execute any SQL statements 
in that database -- you get the same error you get with features not supported 
in the current release. ?I suspect the same thing would happen here.

Peter 


 On Wednesday, October 7, 2015 1:27 PM, Simon Slavin  wrote:




On 7 Oct 2015, at 8:42pm, Richard Hipp  wrote:

> New documentation covering indexes on expressions has been added.
> Please let me know if you think more is needed.

I tentatively suggest that modifications be made to the text describing



and



.? However it may be that such changes would just lengthen the explanation 
without adding anything useful, and that any programmer who tries out those 
PRAGMAs with the new indexes won't have any trouble understanding what they see.

It also might be useful to produce a -2 in the second output column for 
index_xinfo, for columns which are calculations.

I wonder what happens if an index is defined which uses an application-defined 
functions, and a later attempt is made to use the database without that 
function defined.? I can see an argument for returning an error when any 
relevant SELECT is attempted.? But I can also see an argument for returning an 
error only when an attempt is made to INSERT or UPDATE into the indexed table.

Simon.
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite version 3.8.12 enters testing

[Peter Aronson]

I assume, like with similar enhancements, a database created at SQLite 3.8.12 
with an expression index will be unreadable with earlier versions of SQLite? 
?As, for instance, a database created at 3.8.11 with an index with a where 
clauses causes SQLite 3.715.2 to fail when trying execute any SQL statements 
with "Error: malformed database schema (index name) - near "where": syntax 
error?

Peter 


 On Wednesday, October 7, 2015 12:42 PM, Richard Hipp  
wrote:



 On 10/7/15, Zsb?n Ambrus  wrote:
>
> I have concerns with the [indexes on expressions] documentation.
>

New documentation covering indexes on expressions has been added.
Please let me know if you think more is needed.
-- 
D. Richard Hipp
drh at sqlite.org
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite version 3.8.12 enters testing

[Zsbán Ambrus]

On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp  wrote:
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.

I have concerns with the documentation.

"http://sqlite.org/draft/changes.html; mentions "Added support for
indexes on expressions.", and points to
"http://sqlite.org/draft/lang_createindex.html; which tells that an
index row may contain an expression computed from the columns of the
table row.  This implies that an index could be ordered by such an
expression, or it could just cover such an expression if the previous
columns of that index determine the sort order uniquely.

However, I have not seen anything in
"http://sqlite.org/draft/optoverview.html; on how such an expression
column in an index can be used.  Section 1.0 in that document does not
seem to indicate that sqlite can use an expression index to satisfy a
WHERE clause involving an expression computed from a column.
According to section 6.0, this seems to imply that such indexes also
cannot be used to satisfy the ON clause of a JOIN.  Section 8.0
mentions only columns, so I can't tell whether sqlite will use the
expression column of an index to get the value of a result-column
expression of a SELECT from the index, without having to get the value
of the columns involved in the expression from the table, if those
columns aren't in the index.  Section 9.0 seems the most vague, I
can't tell from that whether sqlite can use an index on an expression
to speed u pa SELECT with an ORDER BY clause on the same expression.

It would be nice if you could modify
"http://sqlite.org/draft/optoverview.html; to explicitly mention how
an index on an expression can be used.  If sqlite cannot yet use
indexes on expressions in any way, but only create and maintain them,
making them effectively useless until a future version of sqlite that
will be able to use them, then instead mention that fact in
"http://sqlite.org/draft/lang_createindex.html; .

Thanks,

Zsb?n Ambrus

[sqlite] SQLite version 3.8.12 enters testing

[Dominique Devienne]

On Wed, Oct 7, 2015 at 4:42 PM, Richard Hipp  wrote:

> The release checklist for version 3.8.12
> (https://www.sqlite.org/checklists/3081200/index) is now active.  The
> 3.8.12 release will occur when the checklist goes all-green.
>
> A preliminary change log for version 3.8.12 can be seen at
> https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
> documentation can be seen at https://www.sqlite.org/draft/
>
> If you have issues or concerns with the current SQLite trunk, please
> speak up *now*.
>

Could you please provide links to the amalgamation? TIA, --DD

[sqlite] SQLite version 3.8.12 enters testing

[Scott Robison]

On Wed, Oct 7, 2015 at 3:00 PM, Darren Duncan 
wrote:

> Semantic versioning in general doesn't have any specific format, it just
> means that within a project the succession of version numbers conveys
> information by itself.  There's no requirement there has to be 3 parts or
> whatever.  I consider SQLite's versioning scheme to both be very
> appropriate and it is semantic versioning, not just like such.
>


I agree with you completely when it comes to "semantic versioning".
Unfortunately, someone has defined "Semantic Versioning" at
http://semver.org/ and they are a lot more picky than you or I about what
it should mean.

I have the same "complaint" with "web services". I've been writing / using
them since before they were really defined, but in an ad hoc manner.
Unfortunately, since they've become popular and many standards have been
written about them, some people seem to think what you've written is not a
"Web Service" unless it adheres to some standard like SOAP or WDSL or other
annoying acronym.

>From this point of view, "web service" != "Web Service" and "semantic
versioning" != "Semantic Versioning".

-- 
Scott Robison

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

On 10/7/15, Peter Aronson  wrote:
> I assume, like with similar enhancements, a database created at SQLite
> 3.8.12 with an expression index will be unreadable with earlier versions of
> SQLite?  As, for instance, a database created at 3.8.11 with an index with a
> where clauses causes SQLite 3.715.2 to fail when trying execute any SQL
> statements with "Error: malformed database schema (index name) - near
> "where": syntax error?

Correct.  On the other hand, a database created using 3.8.12 that does
NOT use new features, should be readable and writable by all prior
versions of SQLite.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

On 10/7/15, Zsb?n Ambrus  wrote:
>
> I have concerns with the [indexes on expressions] documentation.
>

New documentation covering indexes on expressions has been added.
Please let me know if you think more is needed.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLite version 3.8.12 enters testing

[Darren Duncan]

Semantic versioning in general doesn't have any specific format, it just means 
that within a project the succession of version numbers conveys information by 
itself.  There's no requirement there has to be 3 parts or whatever.  I 
consider 
SQLite's versioning scheme to both be very appropriate and it is semantic 
versioning, not just like such.

As a digression, for my own projects I like to use a semantic versioning scheme 
of 4 parts like [major.branch.incompatible.compatible] that works like this 
(assume generally each increment of a part means subsequent parts reset to 
zeros):

1. Incrementing 'major' means what it typically means, a substantial rewrite 
that is free to be arbitrarily different and incompatible with the prior major.

2. The 'branch' is inspired by Perl's versioning scheme, in that it alternates 
between even and odd numbers where even means production and odd means 
development.  When one is making changes that are large enough that there 
should 
be dev releases first, eg alpha/beta/etc, a development branch is created and 
those releases are x.odd.y.z until they're considered production ready, then, 
the development branch becomes a maintenance branch and releases become 
x.even.y.z etc.  So example first production releases are 1.0.0.0 or 1.2.0.0 
etc 
while first dev/alpha/etc releases are 1.1.0.0 and 1.3.0.0 etc.  Each branch 
may 
be but isn't necessarily incompatible with prior ones.

3. Incrementing 'incompatible' means that some change was made that is known to 
break at least some use case, whatever the reason for it, and this was done 
without having a separate branch / dev-prod status flip.  This includes 
security 
fixes that disallow something previously allowed.

4. Incrementing 'compatible' means that the authors consider the change to not 
break anything / be fully backwards-compatible, whether due to being a new 
feature or a bug fix.

-- Darren Duncan

On 2015-10-07 1:13 PM, Scott Robison wrote:
> Really, the SQLite3 versioning isn't that far off from Semantic Versioning.
> Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH.
>
> Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading
> through the release history it is fairly clear that a change in MAJOR
> usually results from MAJOR new functionality, MINOR is for relatively MINOR
> new functionality, and PATCH is apparently never used outside that context.
>
> While I personally have no complaints with people who use Semantic
> Versioning, I don't see SQLite versioning as being horribly incompatible
> with it. In fact, if I were making the decision, I'd keep the current
> versioning.
>

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

On 10/7/15, Dominique Devienne  wrote:
>
> Could you please provide links to the amalgamation? TIA, --DD

https://www.sqlite.org/download.html - the first link at the top of
the list of products.
-- 
D. Richard Hipp
drh at sqlite.org

[sqlite] SQLite version 3.8.12 enters testing

[Richard Hipp]

The release checklist for version 3.8.12
(https://www.sqlite.org/checklists/3081200/index) is now active.  The
3.8.12 release will occur when the checklist goes all-green.

A preliminary change log for version 3.8.12 can be seen at
https://www.sqlite.org/draft/releaselog/3_8_12.html and preliminary
documentation can be seen at https://www.sqlite.org/draft/

If you have issues or concerns with the current SQLite trunk, please
speak up *now*.

-- 
D. Richard Hipp
drh at sqlite.org