Re: Direct-to-Field mappings now implemented.
I think this is a good idea. However, I wonder if it is necessary to add the extra syntax? Could we be smart enough to use a getter/setter if one exists, else resort to direct field access? Then there would be no need for the extra parenthesis syntax. Jeff Butler On 2/9/07, Clinton Begin [EMAIL PROTECTED] wrote: Hi all, I found a few hours tonight to implement direct-to-field mappings. I don't have any energy left to explain it fully, but it's simple to use, so here's the summary. To implement this, I changed the ClassInfo to accept a new pattern of property access. You can now wrap a field names in round brackets to distinguish them from properties. So: id is a property. (id) is a field. These can be mixed with properties like: account.(address).street This last point is important and is the primary reason I didn't use a new XML tag -- that would have severely limited the mix-n-match ability of the feature (and it would have been harder to implement). This approach works for reads and writes and for both inline or external parameter maps and result maps. It should be ubiquitous. Anywhere you used to use property names, you can now use (field) names too. Thoughts? It's not too late to change the syntax (round brackets) or anything else. I think it's the simplest, most flexible and performant approach. Cheers, Clinton
Re: Direct-to-Field mappings now implemented.
I agree with Jeff that an alternative syntax is questionable and likely unnecessary. The syntax for accessing members of an object should be the same, regardless if the property is an instance variable or method. Rather, there should be a flag which enables direct property access which will be used if no property method exists. If you're concerned about performance, the probe should record the best route so that this check isn't done every time. I recommend a new configuration setting be allowed in the global configuration and (for overriding) on the resultMap: resultMap ... directFieldAccessFallback=true property col=street name=account.address.street /resultMap Paul On 2/9/07, Jeff Butler [EMAIL PROTECTED] wrote: I think this is a good idea. However, I wonder if it is necessary to add the extra syntax? Could we be smart enough to use a getter/setter if one exists, else resort to direct field access? Then there would be no need for the extra parenthesis syntax. Jeff Butler On 2/9/07, Clinton Begin [EMAIL PROTECTED] wrote: Hi all, I found a few hours tonight to implement direct-to-field mappings. I don't have any energy left to explain it fully, but it's simple to use, so here's the summary. To implement this, I changed the ClassInfo to accept a new pattern of property access. You can now wrap a field names in round brackets to distinguish them from properties. So: id is a property. (id) is a field. These can be mixed with properties like: account.(address).street This last point is important and is the primary reason I didn't use a new XML tag -- that would have severely limited the mix-n-match ability of the feature (and it would have been harder to implement). This approach works for reads and writes and for both inline or external parameter maps and result maps. It should be ubiquitous. Anywhere you used to use property names, you can now use (field) names too. Thoughts? It's not too late to change the syntax (round brackets) or anything else. I think it's the simplest, most flexible and performant approach. Cheers, Clinton
RE: Direct-to-Field mappings now implemented.
Your point is interesting, but wouldn't the () notation break maps transparency? -Original Message- From: Clinton Begin [mailto:[EMAIL PROTECTED] Sent: Friday, 09 February 2007 14:00 To: dev@ibatis.apache.org Subject: Re: Direct-to-Field mappings now implemented. It would be easy to do what you describe (very easy actually). And performance would not suffer at all. However, I did it specifically because of JavaBean syntax and naming conflicts. 99% of JavaBeans are written using something like: String name; public String getName(); Hence a naming conflict between the field name and the property name. The .NET version does exactly what you describe, and to be honest, I did not like it at all. It was very unintuitive and it had me guessing which it would use. Also, one of my early design mistakes (IMHO) was making maps transparent by using the same .dot notation as JavaBeans properties. I feel it was a mistake to do so. iBATIS has a good history of being predictable because it avoids guessing and magic. When I read a SQL Map, I know exactly what it's going to do and where my data is going to go (with the exception of the hashmap issue). To ensure that it stays that way, I personally think being explicit here is the best route. Can anyone else support the points made by Paul and Jeff? Thoughts? Clinton On 2/9/07, Paul Benedict [EMAIL PROTECTED] wrote: I agree with Jeff that an alternative syntax is questionable and likely unnecessary. The syntax for accessing members of an object should be the same, regardless if the property is an instance variable or method. Rather, there should be a flag which enables direct property access which will be used if no property method exists. If you're concerned about performance, the probe should record the best route so that this check isn't done every time. I recommend a new configuration setting be allowed in the global configuration and (for overriding) on the resultMap: resultMap ... directFieldAccessFallback=true property col=street name= account.address.street /resultMap Paul On 2/9/07, Jeff Butler [EMAIL PROTECTED] wrote: I think this is a good idea. However, I wonder if it is necessary to add the extra syntax? Could we be smart enough to use a getter/setter if one exists, else resort to direct field access? Then there would be no need for the extra parenthesis syntax. Jeff Butler On 2/9/07, Clinton Begin [EMAIL PROTECTED] wrote: Hi all, I found a few hours tonight to implement direct-to-field mappings. I don't have any energy left to explain it fully, but it's simple to use, so here's the summary. To implement this, I changed the ClassInfo to accept a new pattern of property access. You can now wrap a field names in round brackets to distinguish them from properties. So: id is a property. (id) is a field. These can be mixed with properties like: account.(address).street This last point is important and is the primary reason I didn't use a new XML tag -- that would have severely limited the mix-n-match ability of the feature (and it would have been harder to implement). This approach works for reads and writes and for both inline or external parameter maps and result maps. It should be ubiquitous. Anywhere you used to use property names, you can now use (field) names too. Thoughts? It's not too late to change the syntax (round brackets) or anything else. I think it's the simplest, most flexible and performant approach. Cheers, Clinton
Re: Direct-to-Field mappings now implemented.
Yes it would. It's transparency vs. expressiveness and control. I guess it would make it harder to refactor (i.e. encapsulate) a field to a setter method later. HmmmI'm slowly being won over. Keep going and you'll have me. ;-) Does anyone like the (brackets)? If I'm the only one, I'll ditch them. Clinton On 2/9/07, Poitras Christian [EMAIL PROTECTED] wrote: Your point is interesting, but wouldn't the () notation break maps transparency? -Original Message- From: Clinton Begin [mailto:[EMAIL PROTECTED] Sent: Friday, 09 February 2007 14:00 To: dev@ibatis.apache.org Subject: Re: Direct-to-Field mappings now implemented. It would be easy to do what you describe (very easy actually). And performance would not suffer at all. However, I did it specifically because of JavaBean syntax and naming conflicts. 99% of JavaBeans are written using something like: String name; public String getName(); Hence a naming conflict between the field name and the property name. The .NET version does exactly what you describe, and to be honest, I did not like it at all. It was very unintuitive and it had me guessing which it would use. Also, one of my early design mistakes (IMHO) was making maps transparent by using the same .dot notation as JavaBeans properties. I feel it was a mistake to do so. iBATIS has a good history of being predictable because it avoids guessing and magic. When I read a SQL Map, I know exactly what it's going to do and where my data is going to go (with the exception of the hashmap issue). To ensure that it stays that way, I personally think being explicit here is the best route. Can anyone else support the points made by Paul and Jeff? Thoughts? Clinton On 2/9/07, Paul Benedict [EMAIL PROTECTED] wrote: I agree with Jeff that an alternative syntax is questionable and likely unnecessary. The syntax for accessing members of an object should be the same, regardless if the property is an instance variable or method. Rather, there should be a flag which enables direct property access which will be used if no property method exists. If you're concerned about performance, the probe should record the best route so that this check isn't done every time. I recommend a new configuration setting be allowed in the global configuration and (for overriding) on the resultMap: resultMap ... directFieldAccessFallback=true property col=street name= account.address.street /resultMap Paul On 2/9/07, Jeff Butler [EMAIL PROTECTED] wrote: I think this is a good idea. However, I wonder if it is necessary to add the extra syntax? Could we be smart enough to use a getter/setter if one exists, else resort to direct field access? Then there would be no need for the extra parenthesis syntax. Jeff Butler On 2/9/07, Clinton Begin [EMAIL PROTECTED] wrote: Hi all, I found a few hours tonight to implement direct-to-field mappings. I don't have any energy left to explain it fully, but it's simple to use, so here's the summary. To implement this, I changed the ClassInfo to accept a new pattern of property access. You can now wrap a field names in round brackets to distinguish them from properties. So: id is a property. (id) is a field. These can be mixed with properties like: account.(address).street This last point is important and is the primary reason I didn't use a new XML tag -- that would have severely limited the mix-n-match ability of the feature (and it would have been harder to implement). This approach works for reads and writes and for both inline or external parameter maps and result maps. It should be ubiquitous. Anywhere you used to use property names, you can now use (field) names too. Thoughts? It's not too late to change the syntax (round brackets) or anything else. I think it's the simplest, most flexible and performant approach. Cheers, Clinton
Re: Direct-to-Field mappings now implemented.
Poitras and Clinton, I agree. The refactoring argument is pretty strong. Property notation is script-like because the actual means to get to the value (method vs. direct-field access) is totally secondary to the intention. The developer just needs to express the path, and the framework should be intelligent enough to get there. But we can't assume the developer always wants direct-field access, which is why the option must be turned on. PS: -1 on the brackets. Paul
RE: Direct-to-Field mappings now implemented.
I guess you have a point. Probably 90% of developpers won't want to know how the real path used... Even if knowing it is interesting, it might disapoint people to force them to know it in advance. In other cases, getters may include code that will be skipped using direct field access. Now the point to this email is that iBATIS didn't force people to have an idea of the implementation before writting xml files. Changing this habit may reduce the interest of iBATIS as a simple tool for O/R mapping. Personally, I am afraid of the reactions some people will have when they'll begin mixing beans, pojos and maps (all 3 for crazy people only!, but most pojos/maps users). Another problem will arise with resultMaps that will need this notation at the same time (to know if we call a setter or a use the field). I personally think it is to late to force people to change their iBATIS habit. But make sure that they'll know what the framework will do. For instance calling the getter if present, if not accessing the field directly. Maybe the notation can be optionnal and will force iBATIS to try accessing the field first, then the getter if field is not present. Think this would do? Christian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Benedict Sent: Friday, 09 February 2007 15:17 To: dev@ibatis.apache.org Subject: Re: Direct-to-Field mappings now implemented. Poitras and Clinton, I agree. The refactoring argument is pretty strong. Property notation is script-like because the actual means to get to the value (method vs. direct-field access) is totally secondary to the intention. The developer just needs to express the path, and the framework should be intelligent enough to get there. But we can't assume the developer always wants direct-field access, which is why the option must be turned on. PS: -1 on the brackets. Paul
