How about when you have a twos complement integer in your program and
Sqlite decides to return a character string?
Ken wrote:
From the standpoint of data insertions you wouldn't reall need to deal with
datatype correctness since sqlite is typeless.
John Stanton <[EMAIL PROTECTED]> wrote: Why would it be a benefit? You would have to be doing type conversions
all the time.
Ken wrote:
I think the fact that sqlite is typeless actually is a benefit.
I see what you mean now about connecting to obtain the meta info. Maybe that could be embedded in the code as well for the pre-processor.
Thanks for your input.
Joe Wilson wrote: ...and I was trying to disagree with you. ;-)
PRO*C and all such pre-processing SQL code generators actually
_do_ need to connect to a database in order to get the table meta-information
(column types, etc). It is this database meta-information that allows the
user of the pre-processor to write the succinct code you mentioned.
Either you have to supply the column type info, or the tool has to
obtain it somehow. And considering that SQLite is typeless, you have your
work cut out for you.
But don't let my contempt of SQL code generators disuade you.
--- Ken wrote:
yes thats what I'm thinking.. The thing is the amount of code that can be
reduced via the
preprocessor is enormous. Plus the fact that one could also preprocess into the
resulting C code
all sorts of wonderful error handling in a very succinct language construct.
I hapen to perfer the conept of PRO*C, I don't like all of the weird errors
that it generates
and the various modes of operation. I'm advocating something that is a build it
like I tell you
to do, not how you interpret it. Leave out all of the goofy semantic checking
etc.. Just let the
normal C compiler handle that bit. There's no real need to connect to a
sqlitedb just to verify
the table exists.
Ken
Joe Wilson wrote: > Yes, a pre processor, but not a wrapper. A wrapper as
I've seen from the sqlite.org site is
simply a layer on top of the sqlite3 api. I've written my own wrapper. I'm
really looking to
see if instead of inserting an additional layer, the actual code could be
compiled inline into
the sourcing C file, thus a pre processor.
Okay, I see. All the bad memories are coming back now...
I used the PRO*C pre-processor ten years ago.
What a disaster that approach is. Never again.
The code is a mess and debugging is a nightmare.
You actually need a static database schema to run your code-generating
pre-processor against. You change your database schema and your code
generator has some obscure syntax error. If your application crashes
you have to wade through generated code to see WTF is going on.
In the time it takes to chase down problems you could have written
a superior application in a traditional language binding/wrapper.
Just my opinion of course.
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
