Thanks Stephan for your feedback. Bad news for me.
I see two solutions:
- hire a dev for this. I'm not following enough sqlite lists to estimate if
this is feasible. Any opinion?
- hire a QGIS dev to hack a autodetection of type using content of fields.
Ugly, probably slow and prone to errors..
Hi Régis
I'd wish to give you a solution but I'm sorry to have new news about that issue.
I'd be happy if there are any SQlite devs around to give you a
solution in order to make this database more usable (an more SQL
compatible).
Yours, Stefan
2013/6/11 regish
Hi all,
I'm starting to use SQLITE in GIS use cases. I'm facing this view typing
column issue, which prevent my favourite client from interpreting correctly
numeric data types. I'm using QGIS, so I won't be able to map numeric
values (they fall back as text values).
Is there anything new since
On 11/05/2010, at 6:12 PM, Ben Harper wrote:
> To determine the type of columns in a view I use
> SELECT typeof(column) FROM viewname LIMIT something;
>
> Unfortunately if most of the column data is NULL then you can end up having
> to scan the entire table.
Yes, I also do that as a last
To determine the type of columns in a view I use
SELECT typeof(column) FROM viewname LIMIT something;
Unfortunately if most of the column data is NULL then you can end up having to
scan the entire table.
I'm not sure how SQlite calculates these types, but this simple workaround has
been OK for
Right, I don't want to lessen scalability of my application. But I
also don't want to introcude redundancy just because some columns on
the the view lack a type.
I assume SQLite wants to adhere to the relational model which states:
The result of a select statement is another relation. And "A view
> To Pavel: My application reads the column types out in order to pretty
> print the values - as mentioned by Tom - but also to generate a dialog
> for entering new data (of course combined with INSTEAD OF TRIGGERs).
So as I see it: you have some universal code for displaying and
inputing data.
Stefan Keller wrote:
> Thank you, Tom and Dan, for your constructive answers.
>
> To Pavel: My application reads the column types out in order to pretty
> print the values - as mentioned by Tom - but also to generate a dialog
> for entering new data (of course combined with INSTEAD OF TRIGGERs).
>
Thank you, Tom and Dan, for your constructive answers.
To Pavel: My application reads the column types out in order to pretty
print the values - as mentioned by Tom - but also to generate a dialog
for entering new data (of course combined with INSTEAD OF TRIGGERs).
I understand that it's
On 06/05/2010, at 2:51 PM, Dan Bishop wrote:
> BareFeetWare wrote:
>>
>> I've had the same issue. In the end I had to parse my view functions in my
>> own code and look for functions that give a particular type of result. So,
>> for instance, round() gives an integer, round(..., 2) gives a
BareFeetWare wrote:
> On 04/05/2010, at 3:14 AM, Stefan Keller wrote:
>
>
>> But in SQLite if a view column comes from a function result or some
>> computation, then the column type is NULL...!? It's not taking the
>> result-type as mentioned in the manual
>>
On 04/05/2010, at 3:14 AM, Stefan Keller wrote:
> But in SQLite if a view column comes from a function result or some
> computation, then the column type is NULL...!? It's not taking the
> result-type as mentioned in the manual
> (http://www.sqlite.org/lang_select.html) - even when I try to do
> I interpret the silence on the lis that anyone agrees that SQLite has a bug
Generally silence on this list means that everybody disagrees with you
and/or doesn't see enough arguments in your email to even start any
discussion. When everybody agrees that SQLite has a bug you get a lot
of
I interpret the silence on the lis that anyone agrees that SQLite has a bug
because there seems to be no way to get VIEWS returning the column type if the
column is calculated or a function. This also breaks compatibility as
mentioned in
http://www.sqlite.org/datatype3.html ("SQL statement that
Unfortunately the application which reads from this view needs that
all columns are typed - even if the values types deviate from it - and
I think this is a logical assumption. So, I fear I do have only one
chance and SQLite doesn't let me do it:
CREATE VIEW myview AS
SELECT id, name,
On 3 May 2010, at 6:14pm, Stefan Keller wrote:
> But in SQLite if a view column comes from a function result or some
> computation, then the column type is NULL...!? It's not taking the
> result-type as mentioned in the manual
> (http://www.sqlite.org/lang_select.html) - even when I try to do a
> Is there a way to give such columns a type anyway?
I guess you aware that columns in SQLite doesn't have types? They only
have "declared type" (which is arbitrary string used in CREATE TABLE
statement) and affinity. OTOH values in each row have types. And
neither "declared type" nor affinity
I have a question regarding VIEWs in SQLite:
It looks like if SQLite simply copies the column type from the
original table into the corresponding view column. And I know SQLite
implements some 'loose column typing'. That's ok so far.
But in SQLite if a view column comes from a function result
18 matches
Mail list logo
