In the OJB property file you have an entry "SqlGeneratorClass", which allows
you to choose a different generator implementation.

Override SqlGeneratorDefaultImpl. You have to implement a ctor, which calls
the super ctor and a function getPreparedSelectStatement(), which delegates
to your own Statement class.
This means that you handle SELECT statements, the rest (INSERT, DELETE,
UPDATE) is still handeld by SqlGeneratorDefaultImpl. If you want more, you
have to override getPreparedDeleteStatement for DELETE and so on. The class
would look like:

Then you have to write your own statement class (override
SqlSelectStatement). Again, you have to implement the ctors and override the
function appendParameter().
In this function you have to format the concrete value (function
asDBParameter):

        /**
         * Overridden method; appends the Parameter (real value) or the
sub-query.
         * @param value the value of the criteria
         */
        protected void appendParameter(Object value, StringBuffer buf)
        {
                if (value instanceof Query)
                {
                        super.appendSubQuery((Query) value, buf);
                }
                else
                {
                        buf.append(asDBParameter(value));
                }
        }

Since the statements are recursive, you also have to override
getSubQuerySQL:

        /**
         * Convert subQuery to SQL
         * @param subQuery the subQuery value of SelectionCriteria
         */
        protected String getSubQuerySQL(Query subQuery)
        {
                ClassDescriptor cld =
getRoot().cld.getRepository().getDescriptorFor(subQuery.getSearchClass());
                String sql;

                if (subQuery instanceof QueryBySQL)
                {
                        sql = ((QueryBySQL) subQuery).getSql();
                }
                else
                {
                        sql = new DynamicSqlSelectStatement(this,
getPlatform(), cld, subQuery, getLogger()).getStatement();
                }

                return sql;
        }

You have to build your own strategie. I will post our strategies soon.
Greetings, CL

-----Original Message-----
From: Janssen, Roger [mailto:[EMAIL PROTECTED] 
Sent: Mittwoch, 05. März 2008 15:02
To: OJB Users List
Subject: RE: Is it possible to force OJB not use execute a prepared
statement?

Hi Christian,

The problem, I believe, is with the number of parameters (parameter
markers) that crosses a certain boundary. We ran into an upper limit of 2000
(or something like that) on MSSQL server. That is a problem for us because
we sometimes generate queries that have more parameters (yes...
really), and then MSSQL server throws an exception.

So, I am very interested in your solution. It could help solve our problem
as well.

Roger Janssen
iBanx

-----Original Message-----
From: Christian Lipp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2008 2:27 PM
To: 'OJB Users List'
Subject: Potential SPAM:RE: Is it possible to force OJB not use execute a
prepared statement?

Hi Roger,

OJB uses alsways prepared statements as armin said before, but do you have
problems with the prepared statements or with the count of parameter markers
(? in the where clause)?

I am asking because we did a lot of experiments with different
implementations (or specialisations) of SqlGeneratorDefaultImpl. The first
implementation was not using parameter markers at all.
So we used prepared statements without any parameter markers, which comes
close to dynamic statements (at least in my understanding and I think this
is what you need).

I would like to post what we did to discuss it here on the mailing list (we
are using db2 and could increase the performance 40% in online acces and 50%
in batch access).

CL 
 
*************************************************************************
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to  whom it is
addressed.You should not copy, disclose or distribute this communication
without the authority of iBanx bv. iBanx bv is neither liable for the proper
and complete transmission of the information has been maintained nor that
the communication is free of viruses, interceptions or interference.  
 
If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.  




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to