Hi John
> The current API is complete regarding types. It returns both the
> declared type and the type actually stored. There is nothing else.
>
> Note that the actual storage type can vary between rows according to the
> data format, which is why the actual type is returned row by row.
JP wrote:
John Stanton wrote:
I endorse Jay's approach. In our web page software using Sqlite
everything is TEXT except for dates in Sqlite format. We use declared
types to indicate classes of text, such as decimal numbers and dates.
There are no radix conversion involved in data
The current API is complete regarding types. It returns both the
declared type and the type actually stored. There is nothing else.
Note that the actual storage type can vary between rows according to the
data format, which is why the actual type is returned row by row.
JS
sqlite wrote:
Joe Wilson wrote:
I also agree with Ralf's proposal for sqlite3_column_affinity().
(Not that a vote on this topic will likely make a difference. ;-)
Another vote from me.
John Stanton wrote:
I endorse Jay's approach. In our web page software using Sqlite
everything is TEXT except for dates in Sqlite format. We use declared
types to indicate classes of text, such as decimal numbers and dates.
There are no radix conversion involved in data manipulation (apart
Joe Wilson wrote:
I also agree with Ralf's proposal for sqlite3_column_affinity().
(Not that a vote on this topic will likely make a difference. ;-)
I don't think you need a new function, just make
the existing one do the obvious thing right after
you call "prepare".
--- Ralf Junker
I also agree with Ralf's proposal for sqlite3_column_affinity().
(Not that a vote on this topic will likely make a difference. ;-)
--- Ralf Junker <[EMAIL PROTECTED]> wrote:
> I second this.
>
> >I think real problem is that you have a function
> >called "column_type" which doesn't actually
John Stanton wrote:
As you postulated, Sqlite's approach is indeed more rational.
Most SQL implementations use fixed-size records
so it makes more sense for them to enforce each
column's data type exactly - inserting a string
into a column which can only hold a single char
isn't very useful.
I endorse Jay's approach. In our web page software using Sqlite
everything is TEXT except for dates in Sqlite format. We use declared
types to indicate classes of text, such as decimal numbers and dates.
There are no radix conversion involved in data manipulation (apart from
dates), and we
As you postulated, Sqlite's approach is indeed more rational.
As for what you are doing, the way I did a similar thing for
compatibility was to make a function which looks at the declared type
and the actual type and makes the appropriate conversion if necessary to
match the destination
[EMAIL PROTECTED] wrote:
I continue to be bewildered by programmers'
fixation on datatypes. This has been a constant
theme for 6 years now. And in all that time, I
have never been able to figure out why so many
people think they need to know the "type" of a
"column".
The best theory I have
D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> The best theory I have is that people who have
> always driven a stick shift must have difficulty
> driving a car with an automatic transmission
Well Yea!?! That clutch pedal almost threw me thru the windshield...
Hey what's this strap thing for???
On 5/10/06, sqlite <[EMAIL PROTECTED]> wrote:
We're C++ programmers and C++ is all about data types.
It's a statically typed language.
I dealt with it pretty simply in my application. It produces web pages
and web pages are text. Anything I retrieve is always retrieved as text.
No conversions
I second this.
>I think real problem is that you have a function
>called "column_type" which doesn't actually return
>the type of a column. This is counter-intutive.
A more telling name for sqlite3_column_type would probably be sqlite3_cell_type.
>If you could make it return the column
1. Open the required database.
2. Run the sqlquestion
select * from sqlite_master;
you get a declaration of table,namn and types.
// Anders
sqlite skrev:
Roger Binns wrote:
The types point still baffles me. If your code already
knows which column it is dealing with then surely the
code
Roger Binns wrote:
The types point still baffles me. If your code already
knows which column it is dealing with then surely the
code should know what type to expect. (Eg if you are
dealing with a column named 'title' then you would
expect a string)
Let me explain what I was doing...
I was
We're C++ programmers and C++ is all about data types.
It's a statically typed language.
The types point still baffles me. If your code already
knows which column it is dealing with then surely the
code should know what type to expect. (Eg if you are
dealing with a column named 'title' then
Fred Williams wrote:
-Original Message-
From: John Stanton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 10, 2006 7:37 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] How can I get the type of a column?
[EMAIL PROTECTED] wrote:
sqlite <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: John Stanton [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 10, 2006 7:37 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] How can I get the type of a column?
>
>
> [EMAIL PROTECTED] wrote:
> > sqlite <[EMAIL PROTEC
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 10, 2006 7:23 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] How can I get the type of a column?
>
>
> sqlite <[EMAIL PROTECTED]> wrote:
> &
[EMAIL PROTECTED] wrote:
As you mention, this is a constant point of discussion on this board.
To me this would indicate a problem.
Perhaps 'Version 3 Data Types' should be given more prominence under
'Documentation'. Alternatively, perhaps the subject should be touched upon
briefly in
Eric Scouten wrote:
On 10 May 2006, at 16:31, sqlite wrote:
Eric Scouten wrote:
No such thing, really. In SQLite the data types are associated with
the cell, not the column.
Yes, I saw that. I'm not sure it's a good "feature".
Depends on your application. For us, it's been a very natural
cc:
|
| Subject: - Re: [sqlite] How can I get the type of a column?
|
>--
[EMAIL PROTECTED] wrote:
sqlite <[EMAIL PROTECTED]> wrote:
Eric Scouten wrote:
SQLite derives that by parsing the string that you've already found.
I found the method in section 2.1 of this page:
http://www.sqlite.org/datatype3.html
> I think it does store that in some internal fashion, so
[EMAIL PROTECTED] wrote:
sqlite <[EMAIL PROTECTED]> wrote:
Eric Scouten wrote:
SQLite derives that by parsing the string that you've already found.
I found the method in section 2.1 of this page:
http://www.sqlite.org/datatype3.html
> I think it does store that in some internal fashion,
> I found the method in section 2.1 of this page:
> http://www.sqlite.org/datatype3.html
>
>
> > I think it does store that in some internal fashion, so
> > it's not *re-parsing* it constantly, but that is not
> > available through the API.
> >
>
> Pity. I guess I'll have to parse it
sqlite <[EMAIL PROTECTED]> wrote:
> Eric Scouten wrote:
> > SQLite derives that by parsing the string that you've already found.
>
> I found the method in section 2.1 of this page:
> http://www.sqlite.org/datatype3.html
>
>
> > I think it does store that in some internal fashion, so
> > it's
The type can vary according to the data. The "declared type" is what
you declare it to be and the type returned when you get a row is the
type which Sqlite decided it should be based on its format.
You can make the declared type anything you want it to be, for example
"WIDGET" and when you
Eric Scouten wrote:
SQLite derives that by parsing the string that you've already found.
I found the method in section 2.1 of this page:
http://www.sqlite.org/datatype3.html
> I think it does store that in some internal fashion, so
> it's not *re-parsing* it constantly, but that is not
>
On 10 May 2006, at 16:31, sqlite wrote:
Eric Scouten wrote:
No such thing, really. In SQLite the data types are associated
with the cell, not the column.
Yes, I saw that. I'm not sure it's a good "feature".
Depends on your application. For us, it's been a very natural fit. It
may not
Eric Scouten wrote:
No such thing, really. In SQLite the data types are associated with the
cell, not the column.
Yes, I saw that. I'm not sure it's a good "feature".
The "declared type" of a column that you've found is used to establish
preferences for how cells are stored, but it is not
No such thing, really. In SQLite the data types are associated with
the cell, not the column.
The "declared type" of a column that you've found is used to
establish preferences for how cells are stored, but it is not a hard
requirement (unlike most other SQL implementations).
-Eric
On
32 matches
Mail list logo
