> Sqlite lets us advance our storage
> capabilities into a more flexible world.
Sure, but it's not allways a good thing. Usually one column stores related
data.
Related data mostly have the same type. Entering a value of different type is
an error
which is silently ignored. Allowing different
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 4:08 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have explained the problem, which is .NET not Sqlite. You have
apparently done a fine job marrying
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 31, 2007 4:08 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You have explained the problem, which is .NET not Sqlite. You have
> apparently done a f
--- John Stanton <[EMAIL PROTECTED]> wrote:
> Sqlite lets you put in anything as the declared type. "DEAD PARROT",
> "MONGOOSE", "GODZILLA" or "DECIMAL(6,1)" are all acceptable declared
> types. Sqlite makes the underlying type TEXT if it is not obviously
> numeric.
The default affinity type
John Stanton wrote:
Sqlite lets you put in anything as the declared type. "DEAD PARROT",
"MONGOOSE", "GODZILLA" or "DECIMAL(6,1)" are all acceptable declared
types. Sqlite makes the underlying type TEXT if it is not obviously
numeric.
Thanks for the clarification. I wasn't aware of
John Elrick wrote:
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type.
John Elrick schrieb:
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type.
John Stanton wrote:
John Elrick wrote:
SNIP
Introspection would occur via this mechanism and would even move all
introspection for any given system behind a common interface.
Just a thought.
John Elrick
CREATE TABLE already stores the type as its declared type. The user
has that
John Elrick wrote:
Michael Schlenker wrote:
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine,
Michael Schlenker wrote:
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
a particular concept like .NET would be a tragedy.
You might consider developing an SQL engine ideally adapted to .NET.
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 3:56 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re
A. Pagaltzis schrieb:
* Samuel R. Neff <[EMAIL PROTECTED]> [2007-05-30 14:55]:
SQLite's typelessness is an asset if you work only with SQLite
but in any application that uses multiple database engines of
which SQLite is only one supported engine, the non-standard
typelessness is something that
TECTED]
Sent: Wednesday, May 30, 2007 12:04 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Re: CAST
> I for one would be in favor of an option to enforce strict
> typing (compile time option).
"SQLite version 3 will feature two other affinity modes, as follows:
Strict affinity mode. In t
> I for one would be in favor of an option to enforce strict
> typing (compile time option).
"SQLite version 3 will feature two other affinity modes, as follows:
Strict affinity mode. In this mode if a conversion between storage classes is
ever required, the database engine returns an error and
Samuel R. Neff schrieb:
SQLite's typelessness is an asset if you work only with SQLite but in any
application that uses multiple database engines of which SQLite is only one
supported engine, the non-standard typelessness is something that has to be
worked around. I for one would be in favor of
: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 6:56 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You are looking for a fit to one particular restrictive, proprietary
environment. Our approach has been to work with the spirit of Sqlite
and to its strengths
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 3:56 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You are looking for a fit to one particular restrictive, proprietary
> environment. Our a
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 8:40 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have just given an excellent explanation of why the wrapper
approach
is flawed. Think about
- Original Message -
From: "Samuel R. Neff" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Tuesday, May 29, 2007 11:06 AM
Subject: RE: [sqlite] Re: CAST
Actually I'd say he gave a great explanation of why the wrapper approach is
so important. Robert wen
Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 11:40 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
You have just given an excellent explanation of why the wrapper approach
is flawed. Think about
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 8:40 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> You have just given an excellent explanation of why the wrapper
> approach
> is flaw
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 6:18 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
Your comments endorse the approach we took which was to avoid the
wrapper concept entirely with its
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 29, 2007 6:18 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> Your comments endorse the approach we took which was to avoid the
> wrapper concept en
Robert Simpson wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 4:21 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
We actually do that with our Sqlite interfaces. We use the declared
type to specify the type and perform
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 28, 2007 4:21 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
> We actually do that with our Sqlite interfaces. We use the declared
> type to spec
Read about manifest typing and it will become clear.
[EMAIL PROTECTED] wrote:
SQLite does not have a dedicated DATE type.
I know that, but why it does't create appropriate column definition ?
create table tab(col date);
creates a table with "date" type.
create table tab2 as select * from
Robert Simpson wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, May 28, 2007 9:11 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Re: CAST
SQLite does not have a dedicated DATE type.
I know that, but why it does't create appropriate
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 28, 2007 9:11 AM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Re: CAST
>
>
> > SQLite does not have a dedicated DATE type.
>
> I know that, but why it
> SQLite does not have a dedicated DATE type.
I know that, but why it does't create appropriate column definition ?
create table tab(col date);
creates a table with "date" type.
create table tab2 as select * from tab;
also.
This type does't do much, but it can be queried with
29 matches
Mail list logo
