Or my contempt of code generators in general :-) Fred
> -----Original Message----- > From: Ken [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 11, 2007 12:46 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Sqlite Preprocessor > > > 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] > -------------------------------------------------------------- > --------------- > > > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
