Re: [sqlite] Unofficial poll

[Yves Goergen]

On 23.09.2012 12:37 CE(S)T, Baruch Burstein wrote:
> Has anyone ever actually taken advantage of this feature? In what case?

No. And I guess I wouldn't need it. If I need that in other systems, I
simply use the most generic type, varchar/text or blob. This way, at
least it's obvious that text can appear in a column. I don't see any use
in letting the data store accept arbitrary data types.

After all, some code must read and understand the data again! And code
is usually very restricted in what it can do with data. Some values must
be added/multiplied/..., others are concatenated. Each algorithm needs
certain data types, even if the programming language doesn't enforce
them. While you could always use a different data type at your will, you
have to live with the consequences of doing so: bugs and crashes.
Sometimes even unnoticed.

And if the data will not be processed by code, but simply stored for a
user to read it, a simple text column will always do.

I code C# and PHP a lot. C# has a mostly static type system and it has
the great benefit that the compiler can check the entire application
before you need to execute every line of it. PHP doesn't have that
advantage and I regularly produce and find bugs due to that. But also in
PHP, I carefully select the appropriate type (i.e. don't rely on
auto-conversion too much) and rely on it being preserved. That allows me
to add my own type-checking and find bugs a lot faster.

-- 
Yves Goergen - nospam.l...@unclassified.de - http://unclassified.de
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Petite Abeille]

On Sep 23, 2012, at 12:37 PM, Baruch Burstein  wrote:

> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,
> e.g. storing strings in integer columns etc., not to the non-truncating
> system e.g. storing any size number or any length string (which is
> obviously very useful in many cases).
> Has anyone ever actually taken advantage of this feature? In what case?

Not used this feature in SQLite itself, but Oracle has such a construct as 
well, poetically named ANYDATA [1].

Personally, I think I used such polymorphic column type precisely once: to 
store different type of preferences (string, date, number, etc) into one column 
instead of multiple ones. The same effect could have been achieve using just a 
text column I guess.

All in all, I find such typeless columns rather confusing, ungainly to use, and 
error prone, and always take care of casting everything to their appropriate 
type to avoid unexpected surprises. See the many previous threads on the 
mailing list related to type confusion and its unforeseen side-effects...

[1] http://www.orafaq.com/node/1853

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Yuriy Kaminskiy]

Jay A. Kreibich wrote:
> On Sun, Sep 23, 2012 at 09:25:06PM +0400, Yuriy Kaminskiy scratched on the 
> wall:
>> Jim Dodgen wrote:
> 
>>> I program mostly on Perl on Linux and it is a beautiful fit. Example
>>> is I can have a date field with a  POSIX time value (or offset) in it
>>> or another date related value like "unknown"
>> Very bad example. Standard SQL NULL is much better fit for "unknown".
>> Besides, perl at least have "use strict;" and "use warnings;", sqlite does
>> not.
> 
>   Yet SQLite's types are often more clearly defined than Perl's.  Every
>   SQLite value has a specific, known type that will tell you exactly
>   how the bits are stored.  The only difference with SQLite is that
>   columns are allowed to have mixed types.  Don't confuse this with a
>   loosely typed language, however... again: every SQLite value has a
>   specific and known type.
> 
> 
>   From a formal mathematical sense, a relational NULL is considered a
>   "value-less type."  That is, it is treated as a specific data type
>   that's value domain is the null-set.
> 
>   So, if you want to get real formal, all relational databases allow
>   multiple types (at least two) to be assigned to a row attribute.
>   I know that sounds contrived, but when you start to look at NULL
>   handling in SQL in this way, it suddenly makes a lot more sense.
>   And it means that all SQL databases already deal with disjoint types
>   within a column.
> 
>   If formal theory isn't your way thing, I'd point out that "traditional"
>   database do all kinds of automatic type conversions.  When you input
>   a date in MySQL, you do so as a string.  When you get a date or
>   duration value back, it is usually as a string.  If you compare a
>   date column to a literal string (that, one assumes, represents a
>   date) the database will do its best to covert that string to
>   something that makes sense before doing the comparison.  Similar
>   things can be said of different numeric types... "WHERE floatCol < 3" 
>   will do automatic conversions and get on with it.
>   
>   The typical database has all kinds of automatic rules about dealing
>   with different types involved in the same operation.  SQLite has all
>   these rules as well...  and they're all clearly defined, and they all
>   work pretty much the same way.  The fact that a column is only loosely
>   typed really doesn't come into play in a significant way, except that
>   the conversion rules for a comparison may come up in a JOIN, while
>   other databases would typically only see a converted comparison in
>   a WHERE. 
>   
>   The end result is not mass chaos but, rather, rarely a surprise.
>   SQLite does a lot of type conversion-- just like every other database
>   out there-- to deal with disjoint types.  Those conversion rules are
>   well documented and make sense.
> 
> 
> 
>   I'm a bit of purest, and when I first started using SQLite eight
>   years ago, I was also a bit off-put by what I saw as "fast and loose"
>   typing.  Over many years of using SQLite for all kinds of things, I
>   can say that this has never been an issue.  It has never surprised
>   me, it has never caused problems-- and it occasionally has been darn
>   handy.
> 
> 
> 
>   And finally, for anyone that really wants strong typing, that's easy
>   enough to do.  Just add a check constraint to your column defs:
>   
>   CREATE TABLE t (
>   i  integer   CHECK ( typeof( i ) == 'integer' ),
>   t  text  CHECK ( typeof( t ) == 'text' ),
>   r  float CHECK ( typeof( r ) == 'real' ),
>   b  blob  CHECK ( typeof( b ) == 'blob' )
>   );

Won't help with catching error in
DELETE ... WHERE day >= 2012-03-15 -- oops, just deleted records from 1994 year

Won't help with catching error when (SELECT ...) >= (SELECT ...) suddenly uses
string comparison instead of numerical (9 >= 19 vs '9' >= '19').

Yes, sqlite rules documented, yes, you can always explain why it behaved the way
it did, still nasty surprises happens, especially with newbies (and sometimes
not only with newbies).

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Jay A. Kreibich]

On Sun, Sep 23, 2012 at 09:25:06PM +0400, Yuriy Kaminskiy scratched on the wall:
> Jim Dodgen wrote:

> > I program mostly on Perl on Linux and it is a beautiful fit. Example
> > is I can have a date field with a  POSIX time value (or offset) in it
> > or another date related value like "unknown"
> 
> Very bad example. Standard SQL NULL is much better fit for "unknown".
> Besides, perl at least have "use strict;" and "use warnings;", sqlite does
> not.

  Yet SQLite's types are often more clearly defined than Perl's.  Every
  SQLite value has a specific, known type that will tell you exactly
  how the bits are stored.  The only difference with SQLite is that
  columns are allowed to have mixed types.  Don't confuse this with a
  loosely typed language, however... again: every SQLite value has a
  specific and known type.


  From a formal mathematical sense, a relational NULL is considered a
  "value-less type."  That is, it is treated as a specific data type
  that's value domain is the null-set.

  So, if you want to get real formal, all relational databases allow
  multiple types (at least two) to be assigned to a row attribute.
  I know that sounds contrived, but when you start to look at NULL
  handling in SQL in this way, it suddenly makes a lot more sense.
  And it means that all SQL databases already deal with disjoint types
  within a column.

  If formal theory isn't your way thing, I'd point out that "traditional"
  database do all kinds of automatic type conversions.  When you input
  a date in MySQL, you do so as a string.  When you get a date or
  duration value back, it is usually as a string.  If you compare a
  date column to a literal string (that, one assumes, represents a
  date) the database will do its best to covert that string to
  something that makes sense before doing the comparison.  Similar
  things can be said of different numeric types... "WHERE floatCol < 3" 
  will do automatic conversions and get on with it.
  
  The typical database has all kinds of automatic rules about dealing
  with different types involved in the same operation.  SQLite has all
  these rules as well...  and they're all clearly defined, and they all
  work pretty much the same way.  The fact that a column is only loosely
  typed really doesn't come into play in a significant way, except that
  the conversion rules for a comparison may come up in a JOIN, while
  other databases would typically only see a converted comparison in
  a WHERE. 
  
  The end result is not mass chaos but, rather, rarely a surprise.
  SQLite does a lot of type conversion-- just like every other database
  out there-- to deal with disjoint types.  Those conversion rules are
  well documented and make sense.



  I'm a bit of purest, and when I first started using SQLite eight
  years ago, I was also a bit off-put by what I saw as "fast and loose"
  typing.  Over many years of using SQLite for all kinds of things, I
  can say that this has never been an issue.  It has never surprised
  me, it has never caused problems-- and it occasionally has been darn
  handy.



  And finally, for anyone that really wants strong typing, that's easy
  enough to do.  Just add a check constraint to your column defs:
  
  CREATE TABLE t (
i  integer   CHECK ( typeof( i ) == 'integer' ),
t  text  CHECK ( typeof( t ) == 'text' ),
r  float CHECK ( typeof( r ) == 'real' ),
b  blob  CHECK ( typeof( b ) == 'blob' )
  );


   -j


-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Jay A. Kreibich]

On Sun, Sep 23, 2012 at 01:37:59PM +0300, Baruch Burstein scratched on the wall:
> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,
> e.g. storing strings in integer columns etc., not to the non-truncating
> system e.g. storing any size number or any length string (which is
> obviously very useful in many cases).

> Has anyone ever actually taken advantage of this feature? In what case?

  Yes.  Several years ago I had a large read-only database I needed
  to fit onto a flash card.  It mostly consisted of strings that were
  anywhere from a few dozen bytes to a few hundred K.  I wrote
  something that attempted to compress the strings.  If the compressed
  block was smaller than the original string (as was usually the case
  for the longer strings) the compressed string was stored as a BLOB.
  If there was no compression savings (which was not uncommon with the
  smaller strings) the string was simply stored as the string.  With
  the addition of a VIEW and a decode function that basically did,
  "if this is a string, return it; if this is a blob, uncompress it
  and return the string", I was all set.

  I've done a number of similar things in other projects.

  Is it critical?  No.  I'm sure each of us could come up with a
  half-dozen ways to do this kind of thing in a traditional database.
  Did it make my life easier, the code simpler, and the database
  smaller and more compact?  Heck, yes.

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[monari.ad...@juno.com]

My thoughts follow:

Be lenient in what you accept; be stringent in what you produce.

I believe SQLite follows this principle.

Frank.


Richard Hipp wrote:

On Sun, Sep 23, 2012 at 6:37 AM, Baruch Burstein wrote:


I am curious about the usefulness of sqlite's "unique" type handling,



SQLite is not unique in this respect.  Lots of other languages use
flexible, dynamic typing:  Javascript, Perl, Python, Tcl, AWK come quickly
to mind.  SQLite began as a TCL extension, so it should not be surprising
that it follows Tcl's dynamic typing model.




and
so would like to know if anyone has ever actually found any practical use
for it/used it in some project? I am referring to the typeless handling,
e.g. storing strings in integer columns etc., not to the non-truncating
system e.g. storing any size number or any length string (which is
obviously very useful in many cases).
Has anyone ever actually taken advantage of this feature? In what case?



Fossil uses dynamic typing, especially in the general-purpose CONFIG table
where the VALUE field holds strings, integers, and BLOBs, depending on
context.




--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
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

Re: [sqlite] Unofficial poll

[Eleytherios Stamatogiannakis]

Sqlite's dynamic typing made it a natural fit for using it with Python 
UDFs in madIS:


https://code.google.com/p/madis/

Absence of the feature would have complicated the whole "functional 
relational" [*] workflow that madIS uses a *lot*.


l.

[*] Instead of Python functions calling SQL, have SQL call Python functions.

On 23/09/12 13:37, Baruch Burstein wrote:

I am curious about the usefulness of sqlite's "unique" type handling, and
so would like to know if anyone has ever actually found any practical use
for it/used it in some project? I am referring to the typeless handling,
e.g. storing strings in integer columns etc., not to the non-truncating
system e.g. storing any size number or any length string (which is
obviously very useful in many cases).
Has anyone ever actually taken advantage of this feature? In what case?



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Paul van Helden]

I am using this feature a lot. My applications log all changes to the
database, SQL and parameters. So I have an attached log.db with a field for
the SQL and then 32 typeless columns for the parameters. Works like a charm!

On Sun, Sep 23, 2012 at 12:37 PM, Baruch Burstein wrote:

> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,
> e.g. storing strings in integer columns etc., not to the non-truncating
> system e.g. storing any size number or any length string (which is
> obviously very useful in many cases).
> Has anyone ever actually taken advantage of this feature? In what case?
>
> --
> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> ___
> sqlite-users mailing list
> 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

Re: [sqlite] Unofficial poll

[Alek Paunov]

On 23.09.2012 23:59, Simon Slavin wrote:

On 23 Sep 2012, at 9:55pm, Alek Paunov  wrote:

This feature is very useful for storing hierarchical data - XML, JSON, ASTs, 
objects in the script engines (e.g. Lua, Python, ...), etc.


Really ?  I don't know about ASTs, but aren't XML and JSON encodings just 
strings ?  You could encode anything in JSON and keep it in a TEXT column.

In some cases they arrive as strings, in other not - i.e. when they are 
generated or parsed as object structures in the host application 
already. In both cases you usually want to do something meaningful with 
the data afterwards - i.e. need to perform queries (for example to 
select just given class of subnodes and attributes) - so it is not 
feasible to store them as BLOBs, especially if the volume is significant.


Instead you need to "shred" them as sqlite rows (following your favorite 
tree encoding scheme), containing "value" attribute (column) for the 
scalars (the leafs of the hierarchy). Here comes the convenience of the 
sqlite feature in the question - the "value" attribute can contain 
values of any of the basic scalar types in single table.


Contrary, in other (relational) databases you need several tables in the 
form fact_int(..., value integer), fact_float(..., value float), etc - 
which additionally complicates the query code.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Simon Slavin]

On 23 Sep 2012, at 9:55pm, Alek Paunov  wrote:

> This feature is very useful for storing hierarchical data - XML, JSON, ASTs, 
> objects in the script engines (e.g. Lua, Python, ...), etc.

Really ?  I don't know about ASTs, but aren't XML and JSON encodings just 
strings ?  You could encode anything in JSON and keep it in a TEXT column.

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

Re: [sqlite] Unofficial poll

[Alek Paunov]

On 23.09.2012 13:37, Baruch Burstein wrote:

Has anyone ever actually taken advantage of this feature? In what case?

Yes, This feature is very useful for storing hierarchical data - XML, 
JSON, ASTs, objects in the script engines (e.g. Lua, Python, ...), etc.


IMHO, If the understanding of the unique sqlite mechanism of operation 
(as SQL to VM-bytecode compiler) was a little bit more widespread, we 
would have already at least one community compiler for these new 
UnQL-like JSON query languages, targeting VDBE as backend (probably 
written in JS by these enthusiastic node.js generation guys) :-)


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Jim Dodgen]

On Sun, Sep 23, 2012 at 10:25 AM, Yuriy Kaminskiy  wrote:
> Jim Dodgen wrote:
>> I program mostly on Perl on Linux and it is a beautiful fit. Example
>> is I can have a date field with a  POSIX time value (or offset) in it
>> or another date related value like "unknown"
>
> Very bad example. Standard SQL NULL is much better fit for "unknown".
> Besides, perl at least have "use strict;" and "use warnings;", sqlite does 
> not.

On "unknown" was not the best example. but other values could be
"missing from input",  "preferred not to give" or anything else that
fits the problem

with just the null I only get two states. "good, and "bad", sometimes
things for me are more complex


>
> (Not that I expect anything to change here; backward compatibility, 
> requirement
> to keep it "lite", etc; like it or not, we have live with current lax typing 
> system)
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



-- 
Jim Dodgen


Watch our travels at: WinoTrips.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Yuriy Kaminskiy]

Jim Dodgen wrote:
> On Sun, Sep 23, 2012 at 3:37 AM, Baruch Burstein  wrote:
>> I am curious about the usefulness of sqlite's "unique" type handling, and
>> so would like to know if anyone has ever actually found any practical use
>> for it/used it in some project? I am referring to the typeless handling,
>> e.g. storing strings in integer columns etc., not to the non-truncating
>> system e.g. storing any size number or any length string (which is
>> obviously very useful in many cases).
>> Has anyone ever actually taken advantage of this feature? In what case?
>
> I program mostly on Perl on Linux and it is a beautiful fit. Example
> is I can have a date field with a  POSIX time value (or offset) in it
> or another date related value like "unknown"

Very bad example. Standard SQL NULL is much better fit for "unknown".
Besides, perl at least have "use strict;" and "use warnings;", sqlite does not.

(Not that I expect anything to change here; backward compatibility, requirement
to keep it "lite", etc; like it or not, we have live with current lax typing 
system)
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Jim Dodgen]

I program mostly on Perl on Linux and it is a beautiful fit. Example
is I can have a date field with a  POSIX time value (or offset) in it
or another date related value like "unknown"


On Sun, Sep 23, 2012 at 3:37 AM, Baruch Burstein  wrote:
>
> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,
> e.g. storing strings in integer columns etc., not to the non-truncating
> system e.g. storing any size number or any length string (which is
> obviously very useful in many cases).
> Has anyone ever actually taken advantage of this feature? In what case?
>
> --
> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users




--

Jim Dodgen


Watch our travels at: WinoTrips.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Simon Slavin]

On 23 Sep 2012, at 11:37am, Baruch Burstein  wrote:

> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,

I use it in a project where a number could be missing for a number of different 
reasons, each of which have to be handled differently.  So I have just one 
column in and test for NULL and several string values before I treat any other 
value as a number.  But had SQLite not had typeless handling I would just have 
made two columns: one with a text value and one with a number, and the number 
would be valid only if the text column had, say, 'valid' in.  It would have 
just meant writing my code a little differently.

Another time was not in everyday working code, but when I imported a huge set 
of data from a spreadsheet which sometimes had weird values in the cells.  
Normally this requires a lot of clicking going backwards and forwards between 
two documents.  A normal SQL engine would have just left many cells blank, but 
with SQLite it was possible to import the entire spreadsheet in one go, then I 
didn't have to work with the spreadsheet any more and could just do things like

SELECT * FROM deposits WHERE typeof(amount) IS NOT 'integer'

to find the cells with weird values and bit by bit convert them to something 
useful.  In that case, once the data was all in a form I was happy with, I no 
longer needed the typeless nature of SQLite: my everyday code assumed that that 
column was integer or NULL.

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

Re: [sqlite] sqlite Unofficial poll

[Tim Streater]

On 23 Sep 2012 at 11:37, Baruch Burstein  wrote:

> I am curious about the usefulness of sqlite's "unique" type handling, and
> so would like to know if anyone has ever actually found any practical use
> for it/used it in some project? I am referring to the typeless handling,
> e.g. storing strings in integer columns etc., not to the non-truncating
> system e.g. storing any size number or any length string (which is
> obviously very useful in many cases).
> Has anyone ever actually taken advantage of this feature? In what case?

It's hard to say whether I use this feature or not. It's just one less thing to 
worry about. It means I don't have to have extra function calls to be sure that 
some value I'm about to shove into a field has the right type. Since I'm doing 
it from PHP, half the time I don't know anyway whether something is a string or 
an integer. The more one can get the Giant Brain to concern itself with this 
type of thing, so I don't have to, the better. Types - pah! Who needs 'em?

--
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Unofficial poll

[Baruch Burstein]

On Sun, Sep 23, 2012 at 2:23 PM, Richard Hipp  wrote:

> On Sun, Sep 23, 2012 at 6:37 AM, Baruch Burstein  >wrote:
>
> > I am curious about the usefulness of sqlite's "unique" type handling,
>
>
> SQLite is not unique in this respect.  Lots of other languages use
> flexible, dynamic typing:  Javascript, Perl, Python, Tcl, AWK come quickly
> to mind.  SQLite began as a TCL extension, so it should not be surprising
> that it follows Tcl's dynamic typing model.
>

It is unique (to my knowledge) among SQL engines, which is the language
category SQLite falls into. Those others are all general programming
languages which is a very different category.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Unofficial poll

[Baruch Burstein]

I am curious about the usefulness of sqlite's "unique" type handling, and
so would like to know if anyone has ever actually found any practical use
for it/used it in some project? I am referring to the typeless handling,
e.g. storing strings in integer columns etc., not to the non-truncating
system e.g. storing any size number or any length string (which is
obviously very useful in many cases).
Has anyone ever actually taken advantage of this feature? In what case?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users