Am 06.07.2013 18:58, schrieb j.merrill-
There are reasons to want what is in other SQL implementations
implemented with "row_number() OVER (ORDER BY ...)" but
"disconnected Recordsets" or for data "passed across thread-
or machine-boundaries" are definitely NOT valid reasons.
Since they are self-describing containers, which can be created
directly from an SQL-string, they allow for a sort of genericity
whilst designing applications, which just saves a lot of lines of
code - and a row_number(OptionalOffsetToStartFrom)-function *is*
much easier to notate in a View-Definition-script, than to implement
with dedicated lines of code in your programming-language of choice.
Perhaps you think "loops" when you think about retrieving (or
visualizing) DB-Data - (and in this case it is easy to ensure
such a counter of course, if the loop is (or needs to be) always
already there in the first place).
I think: "returned Set-Objects, based on a View-Name and some Params":
- and one line of code, to retrieve them by Command-Object or SQL-string
then I'm free to decide, what to do with that Set-Object...
e.g. direct visualizing in a Grid:
- also one line of code: Grid.DataSource = Recordset
Or I decide to serialize it into a Byte-Array, to be able to
pass it into another thread - or pump it out over sockets, to
satisfy an RPC.
- also one line of code: ByteArray = Recordset.Content
So far I *was* living without that row_number()-feature of course -
no need to explain to me, what can be done at the application-level ...
I've perhaps forgotten more about efficient Application-programming,
than... - arrghh - no, let's not go there... ;-)
The "row number" value as commonly described in this thread is
> completely useless except in the context of one specific
> execution of a particular SQL statement.
In the same spirit as you just wrote above, I could come up with:
"a Round()-function is completely useless, except in the context of..."
or
"multiplying a Field-Value with a constant literal is completely
useless..."
or ...
I can only repeat, what I already wrote in my reply to Keith - it's
only about (just another) convenience-feature - nothing more.
You would need to use the table's primary key value to do any updates
to the original table...
> ...to avoid updating rows that had been changed by other sessions
> users after the initial SELECT.
What does this necessity have to do with my nice, new "per SQL included
RowNumbering"-field (I'd otherwise would have to ensure with dedicated
"non SQL-code")?
You would definitely not want to relate one recordset to another using the
> "row number" value, because executing the exact same SQL statement 1
second
> later could return a completely different "row number" value for
every primary key.
Who said, that those who are asking for the inclusion of a row_number-
feature, are complete DB-newbies, who have to be thaught something as
primitive as the above? ;-)
Olaf
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
