On Sunday, April 14, 2019 at 3:17:46 AM UTC-7, Shrinath agarwal wrote:
>
> Hi Marcin,
>
> I know about Prepare function supported by sql package .My initial
> question was what is better way to pass multiple prepare statements on
> different http handlers .
> ex: we can construct struct like this
>
> type Database struct {
> db *sql.DB
>
> someStmt *sql.Stmt
> // etc.
> }
> but since we have multiple prepare statements this struct will keep on
> increasing so my question was is there any better way provided in golang
> like in java (where we can initialize prepare statement in class
> constructor and use that )
>
On the one hand, this seems like a neat approach, having all the prepared
statements in a struct. On the other hand, the compiler isn't really giving
you any extra help, unless you do more work. By which I mean, instead of
using a generic statement, create methods with the exact set of parameters,
and wrap the call to execute the underlying prepared statement. That way,
the compiler helps ensure that all the parameters to the statement are
correct.
That might be an interesting approach. If the application won't benefit
from that, however, this also seems like it might be optimizing the design
for the wrong characteristics. The approach described prevents lazy loading
- instead requiring preparing all statements when the application starts
the connection...
As best I understand it, the better database drivers will cache all the
prepared statements for you already. Which means it is safe to call
Prepare() in the function where you need it. If the database has seen the
Prepare() call before, and hasn't dropped it from its cache, it will simply
use an already prepared version of the statement. Also, there's a
distinction between calling Prepare() on the database, vs. calling
Prepare() on a transaction. The result of Prepare() on the transaction is
valid for the scope of the transaction, and shouldn't be called after the
end of the transaction. Also, I suspect that Prepare() statements are not
the bottleneck of the application, but whether or not they are, test before
assuming!
Just to illustrate my point about different design characteristics,
alternate approaches:
- A struct that has a "Prepare()" method that takes a label for what is
to be prepared, rather than a statement. That way, if statements are
already prepared, the Prepare() method can just look them up.
- Create an interface for the existing use of the DB object, and
implement caching of Prepare() results yourself. (Do a performance check
first, to see if this even matters!)
Difficult to tell which is the right approach, without further
understanding of the requirements.
Eric.
>
> On Sun, Apr 14, 2019 at 7:59 AM Marcin Romaszewicz <[email protected]
> <javascript:>> wrote:
>
>> Do you mean a SQL prepared statement?
>>
>> Check out the database/sql package. The database connection abstraction
>> has a Prepare function which creates a statement. Keep in mind, that based
>> on your level of concurrency, the statement will be re-prepared in each new
>> connection that's opened up on your behalf. So, what you need to do is keep
>> a persistent instance of sql.DB, which will try to maintain your prepared
>> statements for you.
>>
>>
>> On Sat, Apr 13, 2019 at 10:58 AM <[email protected] <javascript:>>
>> wrote:
>>
>>> Hi Team ,
>>> I am new in go lang ,I want to know is there any recommended way in go
>>> lang to create prepare statement in go lang on application start and pass
>>> it to multiple http handler so that query can be done inside those http
>>> handlers.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>
> --
>
> Thanks and Regards,
>
>
>
> Shri Nath Agarwal
>
> Mobile 9482060723
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
