support for named parameters

[adbsoft]

It's been 6 months that I work with web4j, this is a very good experience

but I do not understand why the SQLStatement class does not support Named Parameters ??

[John O'Hanley]

Hi,

The short answer is simply "because it's not supported directly by the PreparedStatement class". Web4j currently uses an ordering convention for the parameters, not a naming convention. Personally, I find that ordering conventions are usually better than naming conventions.

However, I'm certainly open to exploring the idea of named parameters.

Questions:

1. What issue would named params solve exactly?

2. How would this call change under named params (as an example)?:
Db.fetch(Class, SqlId, Object...)

3. Would there be any changes the underlying SQL statement in your .sql file?

Regards,
- John O'Hanley

[adbsoft]

Thank you for your answer

To answer your questions:

- Named params can be very useful when the query contains a large number of parameters that repeats itself, therefore they avoid the error in the number or order of '?'.

- Example :

A) select  t.code, b.blibli  from tata t, b blabla

  Where t.identifiant = b.tata

and t.titi =?

and t.name =?

and b. blibli  like?

==>

B) select t.code, b.blibli from tata t, b blabla

  Where t.identifiant = b.tata

and t.titi =?

and t.name = :name

and b.blibli like :name

- I propose to keep the same call Db.fetch (Class, SqlId, Object ...). To Add two transformations in the constructor of the class SQLStatement:

- Recreate the Object... aSqlParams. To support duplication of named parameters.

- Change the parameter to replace sqltext ( :name, for example) by '?'.

and so return syntax A from B.

Regards,

[John O'Hanley]

Hi,

I don't know if named params would improve things very much.

It's true that the current ordering convention isn't perfect. There are 2 main defects:

1. passing the wrong number of params. This isn't so bad, since it's always caught quickly, the first time you execute it.

2. passing the params in the wrong order. This is worse. The error may be caught quickly, if types don't match. But the error may *not* be caught quickly, if the types do match - for example, if two permuted fields are both strings, the error may not be caught quickly at all.

But would named params be so much better? I imagine that you would need to pass in name-value pairs in some form. Presumably the name is simply a String, and the value is an Object. What if the name String doesn't match what is in the .sql file? That seems to be similar to error #1 above.

What if you pass the right name, but it's accidentally paired with the wrong value? That seems to be similar to error #2 above.

 - John