Hi Mohit I've been thinking about the SQL executor part of the refactoring effort.
I haven't dived deeply into this now, but here's the main idea: The interface between SQL executor and the rest of the code should be json, not anything sql or related to the Execute API. Anything related to the Execute API should be encapsulated inside the SQL executor class. Basically, the json_in structure is probably what the worker class should pass into Execute API. (There might be something else needed, like I said, I didn't really look at this thoroughly today.) The use case you should have in mind, and why I'm writing this email, is that you should consider a hypothetical scenario in the future where we wan't to use the raw storage engine api to access innodb directly, instead of the Execute API with SQL that we use now. (The reason to do this would be performance. But as long as we focus on functionality, using SQL is very convenient.) Then that could be easily done by replacing the SQL Executor class with another class that uses the storage engine api. That's all. I'm at a conference tomorrow, back online on Friday. henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
