>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] -----------------------------------------------------------------------------
