On wto, mar 04, 2003 at 07:27:28 +0100, Torsten Curdt wrote:
> >Ooops. Torsten, I believe this changed with your refactoring, right?
> >(2.0.5 still uses plain statements in this case) Any idea why you have
> >changed this? (OK, PreparedStatements do have advantages, but)
>
> Yes, I did. IIRC it lead to a much easier handling inside the classes.
> And due to the reported SQL injection I wanted to have as least "simple"
> Statements inside the codebase as possible.
>
> The problem is: the PreparedStatment vs Statement issue is very
> controversial. Especially if you do not reuse the same PreparedStatment
> object. Speed advantage or disadvantage seem to vary from database to
> database.
>
> In general you often get the advice [1] to always use Prepared
> Statements. But some people are reporting it to be slower - others that
> it's faster. So whom shall we kick in the but? Database A user or
> database B user? Of course we could make it... configurable *ring* *ring*
maybe just esql:query and esql:prepared query?
> IMO it is not cocoon's job to use the best method for each individual
> database only because the database engine and/or the driver does not do
> "this" or "that" internally. (Why not file a bug against the driver/db?)
because:
1. if you ask M$ to fix a bug they will send you a nice "Thank you for your
cooperation" and nothing else will happen
2. even if it's something more than that you never know how much you will have
to wait for that
3. you have to power to make the invalid driver usable and the user
won't even notice (sometimes developers cannot choose a database/driver just
like me) - why not use it ?:)
4. wouldn't it be nice that cocoon is always there for you when you need it
with no additional work?
5. see sources - it is already done already (fixes for Informix, Oracle)
> I mean we *could* think about some sort of database capabilites
> database... (weird name;) some sort of an abstraction thing. Chris, you
> remember? I was talking about merging the database abstraction from esql
> and the database modules. That could be the first step ...but I don't
> really know if we really should follow that path.
Cocoon's functionality is fantastic but it's not nice to spend more time
setting up database <-> cocoon connection that actualy use it. If it involves
fixing someone else's problems for our own purposes so be it. Maybe the bug
authors will never fix it but some of us still have to use the product.
For me cocoon is most fantastic as database abstraction layer. This is also
the part of cocoon I most understand. I have little experience in cocoon core,
medium in Java but a lot of in C++/OOP and I'm willing to contribute but I do
not know where to start from. If you need an additional person to solve the
case - take me :)
>
> Anyway, Leszek, could you please check with the same ResultSet type
> (ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY)
> as in the JdbcEsqlQuery?
Sure no problem, gonna make this my first thing to do in the morning
>
> I removed the Statements - so I'll try to help you get this fixed -
> anyhow :)
thanks a lot
ouzo
--
__
| / \ | Leszek Gawron // \\
\_\\ //_/ [EMAIL PROTECTED] _\\()//_
.'/()\'. Phone: +48(600)341118 / // \\ \
\\ // recursive: adj; see recursive | \__/ |
