On Mon, 11 May 2015 14:00:41 +
"Drago, William @ CSG - NARDA-MITEQ" wrote:
> Correct me if I'm wrong, but the only way to read comments is by
> reading back the entire CREATE TABLE string, correct?
Yes, you need to parse it. You search for '--' and '\n'. The chars between them
are the
te] Please confirm what I THINK I know about blobs
>
> On Mon, 11 May 2015 14:00:41 +
> "Drago, William @ CSG - NARDA-MITEQ" wrote:
>
>
> > Correct me if I'm wrong, but the only way to read comments is by
> > reading back the entire CREATE TABLE str
e
> Subject: Re: [sqlite] Please confirm what I THINK I know about blobs
>
> This approach:
>
> CREATE TABLE blob_table (
> ModelNo TEXT,
> SerialNo TEXT,
> VSWR BLOB_DOUBLE
> )
>
> involves comments? I don't see how. Nothing wrong with the comments
> approach
This approach:
CREATE TABLE blob_table (
ModelNo TEXT,
SerialNo TEXT,
VSWR BLOB_DOUBLE
)
involves comments? I don't see how. Nothing wrong with the comments approach,
but this is an approach that just takes advantage of the fact that SQLite does
not have fixed data types.
Eric
From:
On 9 May 2015, at 8:12pm, Drago, William @ CSG - NARDA-MITEQ wrote:
> Best idea yet! Anyone see any issues with this?
It's actually a comment, and SQLite provides ways of putting proper comments in
table definitions:
CREATE TABLE blob_table (
ModelNo TEXT, -- new-style models as used from
> -Original Message-
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-
> users-bounces at mailinglists.sqlite.org] On Behalf Of Eric Hill
> Sent: Saturday, May 09, 2015 2:14 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Ple
The comment approach could work, I guess, but why not just encode the type into
the column's declared type?
CREATE TABLE blob_table (
ModelNo TEXT,
SerialNo TEXT,
VSWR BLOB_DOUBLE
)
That's what I do with numeric columns that I need to identify as actually
containing dates. As I
On Sat, 09 May 2015 06:09:41 -0400
William Drago wrote:
> All,
>
> Say you encounter a blob in a database. There's no way to
> tell if that blob carries bytes, floats, doubles, etc, correct?
>
> Assuming the above is true, then is it always prudent to
> store some metadata along with your
On 5/9/2015 6:40 AM, Eduardo Morras wrote:
> On Sat, 09 May 2015 06:09:41 -0400
> William Drago wrote:
>
>> All,
>>
>> Say you encounter a blob in a database. There's no way to
>> tell if that blob carries bytes, floats, doubles, etc, correct?
>>
>> Assuming the above is true, then is it always
On 5/9/15, William Drago wrote:
> All,
>
> Say you encounter a blob in a database. There's no way to
> tell if that blob carries bytes, floats, doubles, etc, correct?
As far as SQLite is concerned, a BLOB is just bytes. The
interpretation of those bytes (as floats, doubles, a JPEG thumbnail, a
All,
Say you encounter a blob in a database. There's no way to
tell if that blob carries bytes, floats, doubles, etc, correct?
Assuming the above is true, then is it always prudent to
store some metadata along with your blobs so that they can
be identified in the future?
Example table:
My design philosophy is that if I have to think about what something is,
then that thought is a piece of information that should accompany the
blob. Consider ten years from now when someone else is looking at the
database for the first time. Will they know what is in that blob? Column
names
In addition to this, where a BLOB represents something that could often be a
file on a disk, methods used to identify the types of those files could often
be
used. For example, with many binary file types the first few bytes of the file
are signatures for its type, eg with JPEG files for
13 matches
Mail list logo
