Brian Aker wrote:
Hi!
On Sep 26, 2008, at 6:35 AM, Jim Starkey wrote:
Something that I believe warrants reconsideration is prepared
statement handling. I am aware that prepared statements were handled
badly in MySQL, but that doesn't mean they are a bad idea. Prepared
statements enable a compiled statement cache, intrinsically much
faster than parsing, compiling, and optimizing the same statements
over and over and over -- no matter how fast the parser and optimizer
are, not parsing and optimizing is faster.
Agreed. The reason we pulled the current one was that it was just not
the place to start from. The major difference is that I want the
serialized form stored client side, not server side (and we invalidate
as needed to client).
Why? Because then proxies along the way have access as well. I also
believe that the parsed bits won't be that large.
I guess I don't understand this at all. What proxies need this
information and what would they do with it?
If anyone is at all interested, the Falcon native SQL engine has a
very clean reference implementation. In a nutshell, DDL is
interpreted from the syntax tree while DML is compiled into a shared
CompiledStatement and either Statement or PreparedStatement
instance. CompiledStatements with parameters are added to the
compiled statement cache, others are deleted after use (no point is
caching one-time use statements). When a new statement comes in, it
is compared for exact (!) string equality against the set of compiled
statements. For each match, a list of unqualified object names must
be checked against the current default database/schema. For a hit,
it is also necessary to validate access permission (assuming you
still have access permissions).
What file is the code under? I'll make a note to look at your class
when we get to this work.
Falcon uses a very obscure naming convention for code files. The files
CompiledStatement.h and CompiledStatement.cpp, for example, contains the
declaration for the CompiledStatement class declarations and
implementations, respectively. Each include file contains the
declaration of single class and each code file the implementation for a
single class.
The classes of interest are:
CompiledStatement -- shared object representing compiled statement
(also the root of the compiler)
Statement -- an instance of a CompiledStatement without parameters
PreparedStatement -- a subclass of Statement with parameters
Context -- row context instantiated within a Statement or
PreparedStatement
Keep in mind that the Falcon native engine is a C++ implementation of JDBC.
Finally, what's your recommendation for a second Neil Stephenson book?
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
