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 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.
>               >       >
>               >       >
>               >       >
>               >
>               >
>               >
>               >
>
>
>
>
>