← Back to team overview

maria-developers team mailing list archive

Re: Java Connector Coding till 5th June

 


> -----Original Message-----
> From: Puneet Dewan [mailto:puneetd30@xxxxxxxxx]
> 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@xxxxxxxxx>
> 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@xxxxxxxxxxxxxxxx> wrote:
> 
> 
> 
> 
> 		> -----Original Message-----
> 		> From: Puneet Dewan [mailto:puneetd30@xxxxxxxxx]
> 
> 		> Sent: Sonntag, 8. Juni 2014 00:37
> 		> To: Vladislav Vaintroub
> 		> Cc: maria-developers@xxxxxxxxxxxxxxxxxxx
> 		> 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@xxxxxxxxxxxxxxxx> wrote:
> 		>
> 		>
> 		>
> 		>
> 		>       > -----Original Message-----
> 		>       > From: Puneet Dewan [mailto:puneetd30@xxxxxxxxx]
> 		>       > Sent: Samstag, 7. Juni 2014 03:58
> 		>       > To: Vladislav Vaintroub
> 		>       > Cc: maria-developers@xxxxxxxxxxxxxxxxxxx
> 		>       > 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@xxxxxxxxxxxxxxxx> wrote:
> 		>       >
> 		>       >
> 		>       >
> 		>       >
> 		>       >       > -----Original Message-----
> 		>       >       > From: Maria-developers [mailto:maria-
> developers-
> 		>       >       >
> bounces+wlad=montyprogram.com@xxxxxxxxxxxxxxxxxxx] On
> 		>       > Behalf Of
> 		>       >       > Puneet Dewan
> 		>       >       > Sent: Donnerstag, 5. Juni 2014 07:43
> 		>       >       > To: maria-developers@xxxxxxxxxxxxxxxxxxx
> 		>       >       > 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.
> 		>       >
> 		>       >
> 		>       >
> 		>
> 		>
> 		>
> 		>
> 
> 
> 
> 
> 




Follow ups

References