[Maria-developers] Java Connector Coding till 5th June
Hi Everyone, The work done till 5th June: 1.I started studying the connector immediately after my semester exams got over(5th May). 2. Understood the relationship between different classes. 3.Read the MySql documentation for text protocol and map the commands from documentation onto code.This thing gave a clear idea about how things are moving from client to server. 4.Setup the code on Ubuntu using eclipse and tested against database. Setup the Team branch in launchpad. 5.Debug the test classes to see how different classes are interlinked and understood that MySQLProtocol.java is the heart of our JDBC driver. 6.Then I started reading Client Server Protocol documentation i.e ServerSide prepared statement and try to see how and where I have to code it. 7.Then I saw that there is a class MySqlServerSidePreparedStatement.java, Initially I coded the prepareStatement() ,close(),and execute() in that class seperately. But after (Code review) discussion with Massimo, we donot need to use that class. Instead use MySqlPreparedStatement.java to do the same work.So made changes accordingly. 8.I had pushed some of the code which I have written to launchpad and discussed with Massimo last week. 9.Last week I was struck with Wireshark on windows and ubuntu both. I was unable to see the packets going to database and seeing the response. 10.On Monday the problem was resolved as I was using the wrong interface.I should have used loopback.io(127.0.0.1) instead on ubuntu(thanks to Georg). Unfortunately the thing does not work on windows.Tried a lot many times. 11.Now I am working on the execute method of client server protocol as I am getting exception while using that method.Wireshark is playing a great role in how the packets are flowing.
From now I will do weekly blogging and keep everyone updated.
Thanks & Regards Puneet.
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Puneet Dewan Sent: Donnerstag, 5. Juni 2014 07:43 To: maria-developers@lists.launchpad.net Subject: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
7.Then I saw that there is a class MySqlServerSidePreparedStatement.java,
Initially I coded the prepareStatement() ,close(),and execute() in that class seperately.
But after (Code review) discussion with Massimo, we donot need to use that class.
I'm curious. What were the arguments for not using this class? That class MySqlServerSidePreparedStatement.java was created for exactly the purpose of implementing server-side prepared statements (user could choose implementation based on parameter, e.g userServerPrepStmts like in Connector/J). If the idea is that people do not need client-side prepared statements, and server-side the only correct way to go, this is, based on my experience, incorrect. Often, people would want parametrized statements without the overhead of P_S (prepare, execute, close).
Instead use MySqlPreparedStatement.java to do the same work.So made changes accordingly.
Hi Vladislav, Honestly, initially I had thought of using MySqlServerSidePreparedstatement. But after discussion with Georg, I understood it was an overhead. Even when discussed during code review with Massimo we decided to add the *useserverprepstmts *feature using MySqlPreparedStatement and not to use MySqlServerSidePreparedstatement. Because this class just had a prepare and close and not a clear idea why this class was created and almost all methods are empty. We are not removing client side prepared statement feature, both client and server side prepared statement are there and will be used as per the needs.I am just trying to add a *useserverprepstmts* feature usingMySqlPreparedStatement and will be activated from the jdbc url i.e* jdbc:mysql://localhost:3306/test?useServerPrepStmts=true*. If useServerPrepStmts is not used client side prepared statements will be used. Regards Puneet. On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Puneet Dewan Sent: Donnerstag, 5. Juni 2014 07:43 To: maria-developers@lists.launchpad.net Subject: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
7.Then I saw that there is a class MySqlServerSidePreparedStatement.java,
Initially I coded the prepareStatement() ,close(),and execute() in that class seperately.
But after (Code review) discussion with Massimo, we donot need to use that class.
I'm curious. What were the arguments for not using this class? That class MySqlServerSidePreparedStatement.java was created for exactly the purpose of implementing server-side prepared statements (user could choose implementation based on parameter, e.g userServerPrepStmts like in Connector/J).
If the idea is that people do not need client-side prepared statements, and server-side the only correct way to go, this is, based on my experience, incorrect. Often, people would want parametrized statements without the overhead of P_S (prepare, execute, close).
Instead use MySqlPreparedStatement.java to do the same work.So made changes accordingly.
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Samstag, 7. Juni 2014 03:58 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Vladislav,
Honestly, initially I had thought of using MySqlServerSidePreparedstatement. But after discussion with Georg, I understood it was an overhead. This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
Even when discussed during code review with Massimo we decided to add the useserverprepstmts feature using MySqlPreparedStatement and not to use MySqlServerSidePreparedstatement. Because this class just had a prepare and close and not a clear idea why this class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revisi... .. The comment says "CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed. Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStatement class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally." This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
We are not removing client side prepared statement feature, both client and server side prepared statement are there and will be used as per the needs.I am just trying to add a useserverprepstmts feature usingMySqlPreparedStatement and will be activated from the jdbc url i.e jdbc:mysql://localhost:3306/test?useServerPrepStmts=true.
If useServerPrepStmts is not used client side prepared statements will be used.
Right, this makes sense.
Regards
Puneet.
On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Maria-developers [mailto:maria-developers- bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of Puneet Dewan Sent: Donnerstag, 5. Juni 2014 07:43 To: maria-developers@lists.launchpad.net Subject: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
7.Then I saw that there is a class MySqlServerSidePreparedStatement.java,
Initially I coded the prepareStatement() ,close(),and execute() in that class seperately.
But after (Code review) discussion with Massimo, we donot need to use that class.
I'm curious. What were the arguments for not using this class? That class MySqlServerSidePreparedStatement.java was created for exactly the purpose of implementing server-side prepared statements (user could choose implementation based on parameter, e.g userServerPrepStmts like in Connector/J).
If the idea is that people do not need client-side prepared statements, and server-side the only correct way to go, this is, based on my experience, incorrect. Often, people would want parametrized statements without the overhead of P_S (prepare, execute, close).
Instead use MySqlPreparedStatement.java to do the same work.So made changes accordingly.
Hi Vladislav, Honestly, initially I had thought of using
MySqlServerSidePreparedstatement. But after discussion with Georg, I understood it was an overhead. This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
the useserverprepstmts feature using MySqlPreparedStatement and not to use MySqlServerSidePreparedstatement. Because this class just had a prepare and close and not a clear idea why
Yes I am trying to add the new functionality using MySQLPreparedStatement. Even when discussed during code review with Massimo we decided to add this
class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revisi... .. The comment says "CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed. Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStateme nt class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally." This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said. I think we all were looking for this reason as to why this class were created and with above answer, now I am convinced. The advantages of creating a new class MySQLServerSidePreparedStatement will be a *clear separation of concerns*. :) I will discuss with my mentors this week and take the necessary steps.Will continue posting about the steps taken. Regards Puneet. On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Samstag, 7. Juni 2014 03:58 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Vladislav,
Honestly, initially I had thought of using MySqlServerSidePreparedstatement. But after discussion with Georg, I understood it was an overhead. This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
Even when discussed during code review with Massimo we decided to add the useserverprepstmts feature using MySqlPreparedStatement and not to use MySqlServerSidePreparedstatement. Because this class just had a prepare and close and not a clear idea why this class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revisi... .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStatement class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
We are not removing client side prepared statement feature, both client and server side prepared statement are there and will be used as per the needs.I am just trying to add a useserverprepstmts feature usingMySqlPreparedStatement and will be activated from the jdbc url i.e jdbc:mysql://localhost:3306/test?useServerPrepStmts=true.
If useServerPrepStmts is not used client side prepared statements will be used.
Right, this makes sense.
Regards
Puneet.
On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Maria-developers [mailto:maria-developers- > bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of > Puneet Dewan > Sent: Donnerstag, 5. Juni 2014 07:43 > To: maria-developers@lists.launchpad.net > Subject: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
> 7.Then I saw that there is a class MySqlServerSidePreparedStatement.java, > > Initially I coded the prepareStatement() ,close(),and execute()
in
that class > seperately. > > But after (Code review) discussion with Massimo, we donot need to use that > class.
I'm curious. What were the arguments for not using this class? That class MySqlServerSidePreparedStatement.java was created for exactly the purpose of implementing server-side prepared statements (user could choose implementation based on parameter, e.g userServerPrepStmts like in Connector/J).
If the idea is that people do not need client-side prepared statements, and server-side the only correct way to go, this is, based on my experience, incorrect. Often, people would want parametrized statements without the overhead of P_S (prepare, execute, close).
> Instead use MySqlPreparedStatement.java to do the same work.So made > changes accordingly.
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Sonntag, 8. Juni 2014 00:37 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
The advantages of creating a new class MySQLServerSidePreparedStatement will be a clear separation of concerns. :)
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement()would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement I am by no means a big fan of everything object-oriented or of design patterns , however in this case the alternative to server-side specific implementation class seems to be a lots of "if" statements mixed into in existing MySQLPreparedStatement methods .Given that PreparedStatement itself is a rather large interface, I'm afraid that code will go spaghetti way rather easily.
I will discuss with my mentors this week and take the necessary steps.Will continue posting about the steps taken.
Regards
Puneet.
On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Samstag, 7. Juni 2014 03:58 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Vladislav,
Honestly, initially I had thought of using MySqlServerSidePreparedstatement. But after discussion with Georg, I understood it was an overhead.
This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
Even when discussed during code review with Massimo we decided to add the useserverprepstmts feature using MySqlPreparedStatement and not to use MySqlServerSidePreparedstatement. Because this class just had a prepare and close and not a clear idea why this class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java- client/trunk/revision/424 .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStatement class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
We are not removing client side prepared statement feature, both client and server side prepared statement are there and will be used as per the needs.I am just trying to add a useserverprepstmts feature usingMySqlPreparedStatement and will be activated from the jdbc url i.e jdbc:mysql://localhost:3306/test?useServerPrepStmts=true.
If useServerPrepStmts is not used client side prepared statements will be used.
Right, this makes sense.
Regards
Puneet.
On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Maria-developers [mailto:maria-developers- > bounces+wlad=montyprogram.com@lists.launchpad.net] On Behalf Of > Puneet Dewan > Sent: Donnerstag, 5. Juni 2014 07:43 > To: maria-developers@lists.launchpad.net > Subject: [Maria-developers] Java Connector Coding till 5th
June
Hi Puneet,
> 7.Then I saw that there is a class MySqlServerSidePreparedStatement.java, > > Initially I coded the prepareStatement() ,close(),and execute()
that class > seperately. > > But after (Code review) discussion with Massimo, we donot need to use that > class.
I'm curious. What were the arguments for not using this class? That class MySqlServerSidePreparedStatement.java was created for exactly the purpose of implementing server-side prepared statements (user could choose implementation based on parameter, e.g userServerPrepStmts like in Connector/J).
If the idea is that people do not need client-side prepared statements, and server-side the only correct way to go, this is,
in based on my
experience, incorrect. Often, people would want parametrized statements without the overhead of P_S (prepare, execute, close).
> Instead use MySqlPreparedStatement.java to do the same work.So made > changes accordingly.
Hi Vladislav, Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement() would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement I agree with your concerns and initially it was coded in the above way. The answer which you gave : This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revisi... .. The comment says "CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed. Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStateme nt class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally." This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said. Thanks for the above .Neither me nor my mentors were aware about this I guess and that's the reason we decided to add the useServerPrepStmts feature using MySQLPreparedStatement. I will discuss with my mentors and continue posting on the steps being taken. Thanks & Regards Puneet. On Sun, Jun 8, 2014 at 4:08 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Sonntag, 8. Juni 2014 00:37 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
The advantages of creating a new class MySQLServerSidePreparedStatement will be a clear separation of concerns. :)
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement()would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I am by no means a big fan of everything object-oriented or of design patterns , however in this case the alternative to server-side specific implementation class seems to be a lots of "if" statements mixed into in existing MySQLPreparedStatement methods .Given that PreparedStatement itself is a rather large interface, I'm afraid that code will go spaghetti way rather easily.
I will discuss with my mentors this week and take the necessary steps.Will continue posting about the steps taken.
Regards
Puneet.
On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Puneet Dewan [mailto:puneetd30@gmail.com] > Sent: Samstag, 7. Juni 2014 03:58 > To: Vladislav Vaintroub > Cc: maria-developers@lists.launchpad.net > Subject: Re: [Maria-developers] Java Connector Coding till 5th June > > Hi Vladislav, > > > Honestly, initially I had thought of using > MySqlServerSidePreparedstatement. > But after discussion with Georg, I understood it was an overhead.
This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
> Even when discussed during code review with Massimo we decided to add > the useserverprepstmts feature using MySqlPreparedStatement and not to > use MySqlServerSidePreparedstatement. > Because this class just had a prepare and close and not a clear idea why this > class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java- client/trunk/revision/424 .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStatement class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
> We are not removing client side prepared statement feature, both client and > server side prepared statement are there and will be used as per the > needs.I am just trying to add a useserverprepstmts feature > usingMySqlPreparedStatement and will be activated from the jdbc url i.e > jdbc:mysql://localhost:3306/test?useServerPrepStmts=true. > > If useServerPrepStmts is not used client side prepared statements will be > used.
Right, this makes sense.
> > Regards > > Puneet. > > > > > On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub > <wlad@montyprogram.com> wrote: > > > > > > -----Original Message----- > > From: Maria-developers [mailto:maria-developers- > > bounces+wlad=montyprogram.com@lists.launchpad.net] On > Behalf Of > > Puneet Dewan > > Sent: Donnerstag, 5. Juni 2014 07:43 > > To: maria-developers@lists.launchpad.net > > Subject: [Maria-developers] Java Connector Coding till 5th June > > Hi Puneet, > > > > 7.Then I saw that there is a class > MySqlServerSidePreparedStatement.java, > > > > Initially I coded the prepareStatement() ,close(),and execute() in > that class > > seperately. > > > > But after (Code review) discussion with Massimo, we donot need > to use that > > class. > > > I'm curious. What were the arguments for not using this class? That > class MySqlServerSidePreparedStatement.java was created for exactly the > purpose of implementing server-side prepared statements (user could > choose implementation based on parameter, e.g userServerPrepStmts like in > Connector/J). > > If the idea is that people do not need client-side prepared > statements, and server-side the only correct way to go, this is, based on my > experience, incorrect. Often, people would want parametrized statements > without the overhead of P_S (prepare, execute, close). > > > > Instead use MySqlPreparedStatement.java to do the same work.So > made > > changes accordingly. > > >
Hi Vladislav, I had discussed with my mentor regarding the MySQLServerSidePreparedStatement. We are planning to go the same way as discussed in the above mails i.e clear the seperation of concerns MySQLServerSidePreparedStatement will extend from the MYSQLPreparedStatement in order to avoid code duplication as its a big interface. *prepareStatement()* will be a factory method in MySQLConnection to provide the MySQLPreparedStatement or MYSQLServerSidePreparedStatement instance depending on *useServerPrepStmts* value. Your suggestions are welcome. Thanks and Regards Puneet. On Sun, Jun 8, 2014 at 5:31 PM, Puneet Dewan <puneetd30@gmail.com> wrote:
Hi Vladislav,
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement() would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I agree with your concerns and initially it was coded in the above way.
The answer which you gave : This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revisi... .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStateme nt class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
Thanks for the above .Neither me nor my mentors were aware about this I guess and that's the reason we decided to add the useServerPrepStmts feature using MySQLPreparedStatement.
I will discuss with my mentors and continue posting on the steps being taken.
Thanks & Regards Puneet.
On Sun, Jun 8, 2014 at 4:08 PM, Vladislav Vaintroub <wlad@montyprogram.com
wrote:
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Sonntag, 8. Juni 2014 00:37 To: Vladislav Vaintroub Cc: maria-developers@lists.launchpad.net Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Puneet,
The advantages of creating a new class MySQLServerSidePreparedStatement will be a clear separation of concerns. :)
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement()would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I am by no means a big fan of everything object-oriented or of design patterns , however in this case the alternative to server-side specific implementation class seems to be a lots of "if" statements mixed into in existing MySQLPreparedStatement methods .Given that PreparedStatement itself is a rather large interface, I'm afraid that code will go spaghetti way rather easily.
I will discuss with my mentors this week and take the necessary steps.Will continue posting about the steps taken.
Regards
Puneet.
On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Puneet Dewan [mailto:puneetd30@gmail.com] > Sent: Samstag, 7. Juni 2014 03:58 > To: Vladislav Vaintroub > Cc: maria-developers@lists.launchpad.net > Subject: Re: [Maria-developers] Java Connector Coding till 5th June > > Hi Vladislav, > > > Honestly, initially I had thought of using > MySqlServerSidePreparedstatement. > But after discussion with Georg, I understood it was an overhead.
This is why I asked. I'm wondering what was the overhead exactly? And what is the plan to avoid the overhead? Is it to squeeze second implementation of java.sql.PreparedStatement interface into an already existing class?
> Even when discussed during code review with Massimo we decided to add > the useserverprepstmts feature using MySqlPreparedStatement and not to > use MySqlServerSidePreparedstatement. > Because this class just had a prepare and close and not a clear idea why this > class was created and almost all methods are empty.
This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java- client/trunk/revision/424 .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStatement class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
> We are not removing client side prepared statement feature, both client and > server side prepared statement are there and will be used as per the > needs.I am just trying to add a useserverprepstmts feature > usingMySqlPreparedStatement and will be activated from the jdbc url i.e > jdbc:mysql://localhost:3306/test?useServerPrepStmts=true. > > If useServerPrepStmts is not used client side prepared statements will be > used.
Right, this makes sense.
> > Regards > > Puneet. > > > > > On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub > <wlad@montyprogram.com> wrote: > > > > > > -----Original Message----- > > From: Maria-developers [mailto:maria-developers- > > bounces+wlad=montyprogram.com@lists.launchpad.net] On > Behalf Of > > Puneet Dewan > > Sent: Donnerstag, 5. Juni 2014 07:43 > > To: maria-developers@lists.launchpad.net > > Subject: [Maria-developers] Java Connector Coding till 5th June > > Hi Puneet, > > > > 7.Then I saw that there is a class > MySqlServerSidePreparedStatement.java, > > > > Initially I coded the prepareStatement() ,close(),and execute() in > that class > > seperately. > > > > But after (Code review) discussion with Massimo, we donot need > to use that > > class. > > > I'm curious. What were the arguments for not using this class? That > class MySqlServerSidePreparedStatement.java was created for exactly the > purpose of implementing server-side prepared statements (user could > choose implementation based on parameter, e.g userServerPrepStmts like in > Connector/J). > > If the idea is that people do not need client-side prepared > statements, and server-side the only correct way to go, this is, based on my > experience, incorrect. Often, people would want parametrized statements > without the overhead of P_S (prepare, execute, close). > > > > Instead use MySqlPreparedStatement.java to do the same work.So > made > > changes accordingly. > > >
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Mittwoch, 16. Juli 2014 08:15 To: Vladislav Vaintroub Cc: Maria Developers Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Vladislav,
I had discussed with my mentor regarding the MySQLServerSidePreparedStatement.
We are planning to go the same way as discussed in the above mails i.e clear the seperation of concerns MySQLServerSidePreparedStatement will extend from the MYSQLPreparedStatement in order to avoid code duplication as its a big interface. prepareStatement() will be a factory method in MySQLConnection to provide the MySQLPreparedStatement or MYSQLServerSidePreparedStatement instance depending on useServerPrepStmts value.
Your suggestions are welcome.
Hi Puneet, This is great to hear. If you have a repository where you have your changes, it could be interesting to have a look at it. Best, Vladislav
Thanks and Regards
Puneet.
On Sun, Jun 8, 2014 at 5:31 PM, Puneet Dewan <puneetd30@gmail.com> wrote:
Hi Vladislav,
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement() would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I agree with your concerns and initially it was coded in the above way.
The answer which you gave : This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java- client/trunk/revision/424 <http://bazaar.launchpad.net/%7Emaria- captains/mariadb-java-client/trunk/revision/424> .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStateme nt class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
Thanks for the above .Neither me nor my mentors were aware about this I guess and that's the reason we decided to add the useServerPrepStmts feature using MySQLPreparedStatement.
I will discuss with my mentors and continue posting on the steps being taken.
Thanks & Regards
Puneet.
On Sun, Jun 8, 2014 at 4:08 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Puneet Dewan [mailto:puneetd30@gmail.com]
> Sent: Sonntag, 8. Juni 2014 00:37 > To: Vladislav Vaintroub > Cc: maria-developers@lists.launchpad.net > Subject: Re: [Maria-developers] Java Connector Coding till 5th June >
Hi Puneet,
> The advantages of creating a new class MySQLServerSidePreparedStatement > will be a clear separation of concerns. :)
Back when created this class , I thought something along the lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement()would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I am by no means a big fan of everything object-oriented or of design patterns , however in this case the alternative to server-side specific implementation class seems to be a lots of "if" statements mixed into in existing MySQLPreparedStatement methods .Given that PreparedStatement itself is a rather large interface, I'm afraid that code will go spaghetti way rather easily.
> I will discuss with my mentors this week and take the necessary steps.Will > continue posting about the steps taken. >
> Regards > > Puneet. > > > > > > > > On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub > <wlad@montyprogram.com> wrote: > > > > > > -----Original Message----- > > From: Puneet Dewan [mailto:puneetd30@gmail.com] > > Sent: Samstag, 7. Juni 2014 03:58 > > To: Vladislav Vaintroub > > Cc: maria-developers@lists.launchpad.net > > Subject: Re: [Maria-developers] Java Connector Coding till 5th June > > > > Hi Vladislav, > > > > > > Honestly, initially I had thought of using > > MySqlServerSidePreparedstatement. > > But after discussion with Georg, I understood it was an overhead. > > This is why I asked. I'm wondering what was the overhead exactly? > And what is the plan to avoid the overhead? Is it to squeeze second > implementation of java.sql.PreparedStatement interface into an already > existing class? > > > > Even when discussed during code review with Massimo we decided > to add > > the useserverprepstmts feature using MySqlPreparedStatement > and not to > > use MySqlServerSidePreparedstatement. > > Because this class just had a prepare and close and not a clear idea > why this > > class was created and almost all methods are empty. > > > This is easy to explan and can also be easily found with bzr, or > Launchpad. The file was added in revision 424 > http://bazaar.launchpad.net/~maria-captains/mariadb- java- > client/trunk/revision/424 .. The comment says > > "CONJ21- allow ResultSetMetaData to be retrieved from > preparedStatement, before statement is executed. > > Fix is using server-side prepared statement functionality - prepare > command will return result set metadata among other information. > Introduce MySQLServerSidePreparedStatement class, which in the future > will be able to provide full-featured PreparedStatement functionality, using > server side prepared statements internally." > > > This is the fix for the bug > https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve > ResultSetMetadata priorto /without the execution of statement. This is only > possible with server-side "prepare", no other way around it > The class was meant to be expanded in the future, as the comment > said. > > > > We are not removing client side prepared statement feature, both > client and > > server side prepared statement are there and will be used as per > the > > needs.I am just trying to add a useserverprepstmts feature > > usingMySqlPreparedStatement and will be activated from the jdbc > url i.e > > jdbc:mysql://localhost:3306/test?useServerPrepStmts=true. > > > > If useServerPrepStmts is not used client side prepared statements > will be > > used. > > > Right, this makes sense. > > > > > > Regards > > > > Puneet. > > > > > > > > > > On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub > > <wlad@montyprogram.com> wrote: > > > > > > > > > > > -----Original Message----- > > > From: Maria-developers [mailto:maria- developers- > > > bounces+wlad=montyprogram.com@lists.launchpad.net] On > > Behalf Of > > > Puneet Dewan > > > Sent: Donnerstag, 5. Juni 2014 07:43 > > > To: maria-developers@lists.launchpad.net > > > Subject: [Maria-developers] Java Connector Coding till 5th > June > > > > Hi Puneet, > > > > > > > 7.Then I saw that there is a class > > MySqlServerSidePreparedStatement.java, > > > > > > Initially I coded the prepareStatement() ,close(),and execute() > in > > that class > > > seperately. > > > > > > But after (Code review) discussion with Massimo, we donot > need > > to use that > > > class. > > > > > > I'm curious. What were the arguments for not using this class? > That > > class MySqlServerSidePreparedStatement.java was created for > exactly the > > purpose of implementing server-side prepared statements (user > could > > choose implementation based on parameter, e.g > userServerPrepStmts like in > > Connector/J). > > > > If the idea is that people do not need client-side prepared > > statements, and server-side the only correct way to go, this is, > based on my > > experience, incorrect. Often, people would want parametrized > statements > > without the overhead of P_S (prepare, execute, close). > > > > > > > Instead use MySqlPreparedStatement.java to do the same > work.So > > made > > > changes accordingly. > > > > > > > > > >
Hi Vladislav, I will send the repository link for review after changes are done. Regards Puneet. On Thu, Jul 17, 2014 at 9:53 AM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
-----Original Message----- From: Puneet Dewan [mailto:puneetd30@gmail.com] Sent: Mittwoch, 16. Juli 2014 08:15 To: Vladislav Vaintroub Cc: Maria Developers Subject: Re: [Maria-developers] Java Connector Coding till 5th June
Hi Vladislav,
I had discussed with my mentor regarding the MySQLServerSidePreparedStatement.
We are planning to go the same way as discussed in the above mails i.e clear the seperation of concerns MySQLServerSidePreparedStatement will extend from the MYSQLPreparedStatement in order to avoid code duplication as its a big interface. prepareStatement() will be a factory method in MySQLConnection to provide the MySQLPreparedStatement or MYSQLServerSidePreparedStatement instance depending on useServerPrepStmts value.
Your suggestions are welcome.
Hi Puneet, This is great to hear. If you have a repository where you have your changes, it could be interesting to have a look at it.
Best, Vladislav
Thanks and Regards
Puneet.
On Sun, Jun 8, 2014 at 5:31 PM, Puneet Dewan <puneetd30@gmail.com> wrote:
Hi Vladislav,
Back when created this class , I thought something along the lines
usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement() would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I agree with your concerns and initially it was coded in the above way.
The answer which you gave : This is easy to explan and can also be easily found with bzr, or Launchpad. The file was added in revision 424 http://bazaar.launchpad.net/~maria-captains/mariadb-java- client/trunk/revision/424 <http://bazaar.launchpad.net/%7Emaria- captains/mariadb-java-client/trunk/revision/424> .. The comment says
"CONJ21- allow ResultSetMetaData to be retrieved from preparedStatement, before statement is executed.
Fix is using server-side prepared statement functionality - prepare command will return result set metadata among other information. Introduce MySQLServerSidePreparedStateme nt class, which in the future will be able to provide full-featured PreparedStatement functionality, using server side prepared statements internally."
This is the fix for the bug https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve ResultSetMetadata priorto /without the execution of statement. This is only possible with server-side "prepare", no other way around it The class was meant to be expanded in the future, as the comment said.
Thanks for the above .Neither me nor my mentors were aware about this I guess and that's the reason we decided to add the useServerPrepStmts feature using MySQLPreparedStatement.
I will discuss with my mentors and continue posting on the steps being taken.
Thanks & Regards
Puneet.
On Sun, Jun 8, 2014 at 4:08 PM, Vladislav Vaintroub <wlad@montyprogram.com> wrote:
> -----Original Message----- > From: Puneet Dewan [mailto:puneetd30@gmail.com]
> Sent: Sonntag, 8. Juni 2014 00:37 > To: Vladislav Vaintroub > Cc: maria-developers@lists.launchpad.net > Subject: Re: [Maria-developers] Java Connector Coding till 5th June >
Hi Puneet,
> The advantages of creating a new class MySQLServerSidePreparedStatement > will be a clear separation of concerns. :)
Back when created this class , I thought something along
lines of usual OO technique - single interface, 2 different concrete implementations classes . Connection.prepareStatement()would serve then as a factory method -dependent on useServerPrepStmt connection parameter it would create either MySQLPreparedStatement or MySQLServerSidePreparedStatement
I am by no means a big fan of everything object-oriented or of design patterns , however in this case the alternative to server-side specific implementation class seems to be a lots of "if" statements mixed into in existing MySQLPreparedStatement methods .Given that PreparedStatement itself is a rather large interface, I'm afraid that code will go spaghetti way rather easily.
> I will discuss with my mentors this week and take the necessary steps.Will > continue posting about the steps taken. >
> Regards > > Puneet. > > > > > > > > On Sun, Jun 8, 2014 at 2:04 AM, Vladislav Vaintroub > <wlad@montyprogram.com> wrote: > > > > > > -----Original Message----- > > From: Puneet Dewan [mailto:puneetd30@gmail.com] > > Sent: Samstag, 7. Juni 2014 03:58 > > To: Vladislav Vaintroub > > Cc: maria-developers@lists.launchpad.net > > Subject: Re: [Maria-developers] Java Connector Coding till 5th June > > > > Hi Vladislav, > > > > > > Honestly, initially I had thought of using > > MySqlServerSidePreparedstatement. > > But after discussion with Georg, I understood it was an overhead. > > This is why I asked. I'm wondering what was the overhead exactly? > And what is the plan to avoid the overhead? Is it to squeeze second > implementation of java.sql.PreparedStatement interface into an already > existing class? > > > > Even when discussed during code review with Massimo we decided > to add > > the useserverprepstmts feature using MySqlPreparedStatement > and not to > > use MySqlServerSidePreparedstatement. > > Because this class just had a prepare and close and not a clear idea > why this > > class was created and almost all methods are empty. > > > This is easy to explan and can also be easily found with bzr, or > Launchpad. The file was added in revision 424 > http://bazaar.launchpad.net/~maria-captains/mariadb- java- > client/trunk/revision/424 .. The comment says > > "CONJ21- allow ResultSetMetaData to be retrieved from > preparedStatement, before statement is executed. > > Fix is using server-side prepared statement functionality - prepare > command will return result set metadata among other information. > Introduce MySQLServerSidePreparedStatement class, which in the future > will be able to provide full-featured PreparedStatement functionality, using > server side prepared statements internally." > > > This is the fix for the bug > https://mariadb.atlassian.net/browse/CONJ-21 , to allow users to retrieve > ResultSetMetadata priorto /without the execution of statement. This is only > possible with server-side "prepare", no other way around it > The class was meant to be expanded in the future, as the comment > said. > > > > We are not removing client side prepared statement feature, both > client and > > server side prepared statement are there and will be used as per > the > > needs.I am just trying to add a useserverprepstmts feature > > usingMySqlPreparedStatement and will be activated from the jdbc > url i.e > > jdbc:mysql://localhost:3306/test?useServerPrepStmts=true. > > > > If useServerPrepStmts is not used client side
of the prepared
statements > will be > > used. > > > Right, this makes sense. > > > > > > Regards > > > > Puneet. > > > > > > > > > > On Sat, Jun 7, 2014 at 3:02 PM, Vladislav Vaintroub > > <wlad@montyprogram.com> wrote: > > > > > > > > > > > -----Original Message----- > > > From: Maria-developers [mailto:maria- developers- > > > bounces+wlad=montyprogram.com@lists.launchpad.net] On > > Behalf Of > > > Puneet Dewan > > > Sent: Donnerstag, 5. Juni 2014 07:43 > > > To: maria-developers@lists.launchpad.net > > > Subject: [Maria-developers] Java Connector Coding till 5th > June > > > > Hi Puneet, > > > > > > > 7.Then I saw that there is a class > > MySqlServerSidePreparedStatement.java, > > > > > > Initially I coded the prepareStatement() ,close(),and execute() > in > > that class > > > seperately. > > > > > > But after (Code review) discussion with Massimo, we donot > need > > to use that > > > class. > > > > > > I'm curious. What were the arguments for not using this class? > That > > class MySqlServerSidePreparedStatement.java was created for > exactly the > > purpose of implementing server-side prepared statements (user > could > > choose implementation based on parameter, e.g > userServerPrepStmts like in > > Connector/J). > > > > If the idea is that people do not need client-side prepared > > statements, and server-side the only correct way to go, this is, > based on my > > experience, incorrect. Often, people would want parametrized > statements > > without the overhead of P_S (prepare, execute, close). > > > > > > > Instead use MySqlPreparedStatement.java to do the same > work.So > > made > > > changes accordingly. > > > > > > > > > >
participants (2)
-
Puneet Dewan -
Vladislav Vaintroub