Hi, Well an awkward set of UDFs is better than nothing. Particularly if a web app could run the commands for users. If Drizzle can host a web application, that application could manage the creation and upkeep of the views while calling a rudimentary UDF interface in the background. Flexviews could also exist entirely outside of the database but for the table change logging. The change logging is the part that is tightly coupled to the database implementation.
I forgot about one other change logging requirement: I have to be able to detect what "transaction id" was generated by my last COMMIT. The algorithm depends on this to build the compensation queries. --Justin On Sat, Jul 18, 2009 at 2:44 PM, Jay Pipes <[email protected]> wrote: > > Without additions to the parser, flexviews would have to be implemented as > an awkward set of UDFs... > > This needs to happen for a variety of upcoming plugins, actually, including > some of the replication plugins (publisher and subscriber coming shortly). > Without this functionality, plugins are stuck using only the SQL syntax > currently implemented in Drizzle. > > A bit of an aside...the Drizzle parser, though less than a third the size > of MySQL's, is still a bit of a rat's nest of code. To make it extensible, > we need to add hooks that enable a plugin's own parser methods to be called > when the kernel's parser hits a token it does not understand. So, instead > of bombing a YYABORT(), it needs to call plugins' registered parse routines, > passing in the token stream. > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
