Ok I got your point clearly now. On Fri, Jun 1, 2012 at 3:12 AM, Henrik Ingo <henrik.i...@avoinelama.fi>wrote:
> 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
