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 <[EMAIL PROTECTED]> 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]
-----------------------------------------------------------------------------


Reply via email to