I'm wondering if a patch/solution is in the works to support dynamic select clauses.
Currently if you have a statement such as this one:
<select id="dynamicSelect" parameterClass="java.util.Map" resultClass="java.util.HashMap">
SELECT
<isPropertyAvailable property="countQuery">
count(*)
</isPropertyAvailable>
<isNotPropertyAvailable property="countQuery">
A, B, C
</isNotPropertyAvailable>
FROM [...]
</select>
This statement will break if it is called twice: one time with the "countQuery" and the second without. The problem comes from the fact that an AutoResultMap is created when first calling the statement and reused for subsequent calls to the same statement.
It seems as if iBatis only partially supports dynamic select clauses. You can build a statement in such a way that it returns different columns depending on its parameters, but the resultMap cannot: it must always have the same columns present even when using a Map as the result class.
Please note, I'm using iBatis 2.0.0 RC5. I've read the changelog and the newest SqlMap documentation, but I haven't found anything related to this issue. If it's been fixed, please let me know how it was fixed.
Regards,
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can use dynamic select and/or from clause with the following requirement:
You MUST keep the result set metadata the same. That is, the number of columns, the order of the columns, the column names and the column types must remain the same.
Supporting dynamically changing RSMD would simply create too many performance and design issues.
This may be added as an option in the future for those who are willing to sacrifice performance.
Cheers,
Clinton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Up until now, we've been able to handle this issue with NULL AS columnName for "missing" columns in the SELECT clause. Not a big deal since we need for just a few complex statements.
It has become a problem because we actually hit a situation where the number and name of the columns in the RSMD cannot be known when _building_ the statement. It's a runtime "variable".
The problem I see here is that the SQLMap supports this for statements but not for resultMaps: I can have dynamic SELECT clauses but not dynamic resultMaps.
To me, using a Map as a resultClass is like specifying that the result is dynamic. I don't, a-priori, know what my result will be, otherwise I would've created a resultMap.
I'm not to sure about your performance issue. Is it due to the fact that you need to create the AutoResultMap for every result? Would it be possible to create an AutoResultMap per statement call instead of per statement? Could you elaborate on the performance issue please?
How would the option you're talking about be used? Would it be a statment's attribute? A new kind of resultMap? How about a DynamicResultMap interface? Or would using the java.util.Map interface sufice?
Regards,
Philippe
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to make this a higher priority issue. It's come up enough now that I think it's important for us to deal with.
Version 1.x supported this quite easily. In version 2.x, I decided it was less important than performance. That said, I hope there's an elegant way to achieve both.
Cheers,
Clinton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm wondering if a patch/solution is in the works to support dynamic select clauses.
Currently if you have a statement such as this one:
<select id="dynamicSelect" parameterClass="java.util.Map" resultClass="java.util.HashMap">
SELECT
<isPropertyAvailable property="countQuery">
count(*)
</isPropertyAvailable>
<isNotPropertyAvailable property="countQuery">
A, B, C
</isNotPropertyAvailable>
FROM [...]
</select>
This statement will break if it is called twice: one time with the "countQuery" and the second without. The problem comes from the fact that an AutoResultMap is created when first calling the statement and reused for subsequent calls to the same statement.
It seems as if iBatis only partially supports dynamic select clauses. You can build a statement in such a way that it returns different columns depending on its parameters, but the resultMap cannot: it must always have the same columns present even when using a Map as the result class.
Please note, I'm using iBatis 2.0.0 RC5. I've read the changelog and the newest SqlMap documentation, but I haven't found anything related to this issue. If it's been fixed, please let me know how it was fixed.
Regards,
Phil
hmmm, i wasn't aware that this is a problem. Doesn't seem to me that it should be. Try upgrading to 2.0.7 and let us know if this continues.
Brandon
You can use dynamic select and/or from clause with the following requirement:
You MUST keep the result set metadata the same. That is, the number of columns, the order of the columns, the column names and the column types must remain the same.
Supporting dynamically changing RSMD would simply create too many performance and design issues.
This may be added as an option in the future for those who are willing to sacrifice performance.
Cheers,
Clinton
Up until now, we've been able to handle this issue with NULL AS columnName for "missing" columns in the SELECT clause. Not a big deal since we need for just a few complex statements.
It has become a problem because we actually hit a situation where the number and name of the columns in the RSMD cannot be known when _building_ the statement. It's a runtime "variable".
The problem I see here is that the SQLMap supports this for statements but not for resultMaps: I can have dynamic SELECT clauses but not dynamic resultMaps.
To me, using a Map as a resultClass is like specifying that the result is dynamic. I don't, a-priori, know what my result will be, otherwise I would've created a resultMap.
I'm not to sure about your performance issue. Is it due to the fact that you need to create the AutoResultMap for every result? Would it be possible to create an AutoResultMap per statement call instead of per statement? Could you elaborate on the performance issue please?
How would the option you're talking about be used? Would it be a statment's attribute? A new kind of resultMap? How about a DynamicResultMap interface? Or would using the java.util.Map interface sufice?
Regards,
Philippe
I'm going to make this a higher priority issue. It's come up enough now that I think it's important for us to deal with.
Version 1.x supported this quite easily. In version 2.x, I decided it was less important than performance. That said, I hope there's an elegant way to achieve both.
Cheers,
Clinton
I'm not looking for a date, but I'm wondering when you think this will be available? Does "high priority" mean "next release"?
Also, do you have any idea how this will be implemented? How are users going to use this new feature?
Thanks,
Philippe