This sounds good. So my point is, you have this object you got from JsonThreadPool. Is it called JsonWorker? My point is, the API between JsonWorker and SQL Generator should be generic. Maybe a factory?
So in JsonWorker, you have done the parsing and you have the json_in object. You now access a generic API to get data from database: db = DbAccessorFactory( DbAccessorType::SQL ); // Or maybe a C++ template, I'm not so used to them... db->execute(json_in); Now, what happens in db->execute() is the SQL Generator and SQL Executor. However, in the future we might implement a db access that doesn't use the SQL api but just the raw storage engine api. Then all we would change in the JsonWorker code would be the single line: DbAccessorType::SomethingElse. henrik On Fri, Jun 1, 2012 at 12:08 AM, Mohit Srivastava <srivastavamohi...@gmail.com> wrote: > Hi Henrik , > > I think yeah you are right , but can we do that in this manner : > > HttpHandler : This one take care of http requests. > JsonThreadPool : This one supply threads for each request. > > In short , Handler will ask thread-pool for thread , and whenever it get > some thread , it execute the request. > > Then , We have request with json . So it need to be parse, It can be done > with json parser. > And we need to generate sql query from json and other http stuff. So Sql > Generator helps us in this case. then the generated sql will pass to Sql > Executor. > > So finally we divide sql execute API into two part : generator and executor. > > Thanks > -- > Mohit > > On Thu, May 31, 2012 at 1:37 AM, Henrik Ingo <henrik.i...@avoinelama.fi> > wrote: >> >> 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 > > -- 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
