maria-developers team mailing list archive

[Puneet Dewan <puneetd30@xxxxxxxxx>]

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?

Yes I am trying to add the new functionality using MySQLPreparedStatement.

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