o Better Spring integration (TX Config)
o Repeating group mapping (solution for n+1 selects problem)
o Inheritance via selects or joins (same as groups)
o Cancel long running statements (cross thread)
o CLOB/BLOB support
o Cross file resource management (currently works, but order dependent --ok?)
o RowSet|ResultSet results?
o Multiple result sets/update results
o Extended configuration logging
o Overriding mapped statements (i.e. reuse SQL; overrides="statementName")
o Cache dependency on other cache (flush-on-dependant)
o Flush cache at specifig time (e.g. 22:30)
o Circular relationships
o Deal with XML as DOM rather than String
o Get warnings (conn, ps, rs)
o Type translation filters (e.g. "Y"|"N" -> true|false)
o Pluggable dynamic fragments
o Asynchronous updates (queued)
o Idle Connection Timeout in SimpleDataSource
o Map with 1:M relationship with other Map? (i.e. map key contains list of other maps)
o Per result Lazy Load configuration
o Specify classloader for DAO/SqlMap builders
o Optional results/exclusions (i.e. don't require all results)
o Extended Statements
o Included Statements
o Improved Inline parameters (w/stored proc mode)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From what i can see QDox addresses the specific purpose of parsing the source and extracting various information from the source. Whereas XDoclet has a "code generation" purpose. From looking into the "Who's using it" link on the QDox site it says that XDoclet2 uses Qdox. So, it would seem that if we used QDox we'd be writing some Code Generation functionality that is perhaps taken care of by XDoclet.
But, on a higher level I am curious as to how XDoclet would simplify iBatis development. With the complexities inherent in SQL Mapping, I'm just curious if it really will be that much of a time saver. I'm thinking it will encourage us to place a javadoc attribute in our code that contains a massive sql statement. I understand that you can perform insertions in some way to avoid littering your code with too much "metadata". But, does that really simplify what many are doing now or does it just put the barrier of another "API" to learn in the way. Does it really mandate the use of priority development time?
I don't want to give the impression that I am against XDoclet. I'm simply not clear on how it would be implemented in a way that assists in reducing complexity and increasing productivity.
Could we see some mockup examples/scenarios where it would benefit developers? Would time be best devoted towards creating an IDE plugin that provides a more tailored approach to generating classes/configs for ibatis?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-04-20
Is it possible to elevate type mapping from low to mid?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, XDoclet does a lot more, but also requires a lot more. I like the light weight and low level of QDox. It does just what is needed without overcomplicating everything. I looked at the XDoclet site for about 5 minutes before deciding it was too much. In about 5 minutes on the QDox site, i knew how to use the tool!
As for IDEs, I don't think one replaces the other. I think there is room for both an IDE and an Attribute Oriented Programming solution. I prefer the latter myself, but I think SQL Maps is flexible enough to support a number of development paradigms...including hand coding.
In addition, it seems like Metadata and/or DDL driven solutions are popular already. Although not my personal favourite, I think they're just as valid as any solution.
Lots of fun work ahead!
Clinton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Larry and I discussed this earlier and he brought up a good point. He was thinking the plugins would build upon the attribute programming paradigm rather than work exclusively from a different approach. I think the plugins would allow you to visually map columns to beans, generate beans, basic DAO classes, etc... then it would generate the attributes for you in the class. The plugins would/should be able to also pick up existing attributes and work with them. Also, the attributes generated by the plugins should be usable by a command line option or whatever manner of interacting with the attributes that we build. In that sense QDox sounds like the route I'd prefer to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I looked through the forums and the archives and i couldn't find the discussions Clinton and Vic had about DOM. However, (IMO) I dont think we should limit the manner in which the xml can be returned. I think String is a good way to return it myself. Think of all the APIs that may want to use it and all the different way each of those APIs can work with the xml. Dom4j, JDOM, JAXP, JAXB, Castor are just a few. I use dom4j on an app that works with an xml stream and it reads the xml in as a string. So, perhaps we could write a few implementations for the return type of the xml.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As i was looking through the list a bit more seriously I was wondering if some or all these items can be expounded upon.
o Repeating group mapping (solution for n+1 selects problem)
o Inheritance via selects or joins (same as groups)
o Cancel long running statements (cross thread)
o Cross file resource management (currently works, but order dependent --ok?)
o Multiple result sets/update results
o Extended configuration logging
o Get warnings (conn, ps, rs)
o Asynchronous updates (queued)
o Per result Lazy Load configuration
o Optional results/exclusions (i.e. don't require all results)
o Improved Inline parameters (w/stored proc mode)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All will need to be described in more detail. We should probably have a separate thread for each.
Any thoughts on the format/location for the descriptions of these features? We could rely on this forum, or a tracker. We could also have a more formal document with the description of the feature.
Thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm for putting this stuff into the bug/tracker as an ehancement bug and providing the details there. If we know we need to do them at some point then it is the best place for it. If there is brainstorming discussion to be had on it perhaps we can place a link in the bug to a forum thread and discuss the issue in the forum. Once it is concrete or at least firm we can expound by adding new comments in the bug report.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree... Having a formal tracking system for bugs is essential. It should also be essential for features.
Using the tracker you can associate features to upcomming versions of the framework. It would effectively eliminate unformal priorities (what does "low-priority" mean?) and would help the development process as a whole...
Also, access to CVS should be one of the features in the list, don't you think?
Regards,
Phil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-04-21
I'm looking to migrate my antiquated DAO classes with your DAO framework backed by SQL Maps. I expose web services to .NET clients throughout our enterprise, so for 1:M relationships I'm forced to use strongly typed data sets to represent the many-side of a relationship (arrays). Is it possible, to add array types to represent M in 1:M relationships?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"strongly typed data sets" - do you mean you expose a list of beans?
"array types" - do you mean you want the ability to expose something like MyCustomBean[] instead of an Object[] or a List or Beans?
I guess I'm not understanding 100% of what you are asking for.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-04-21
I apologize for the misunderstanding. I was trying to make a distinction between representing a aggregate relationship as a java.util.Collection and using a BeanType[] array instead. The former being loosely typed from a webservice perspective (how does the webservice consumer know how generate a comparable representation of that Collection), the latter being just an array of beans, which, of course, is supported in SOAP/XML Schema. Being the lone wolf (java) in a den of sheep (.NET), I tend to mix the technologies frequently, hence the world 'data sets' which is used a lot on the .NET side. So the answer to your question is "Yes", I want to be able to populate an array of beans like MyCustomerBean[] instead of a List of Beans using the SQL Maps API.
Thanks,
Lance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
------------------------------
FEATURE REQUESTS: TOOLS
------------------------------
o XDoclet/QDox Tags (@ibatis)
o SQL Map Editor GUI
o Ant Tasks?
------------------------------
FEATURE REQUESTS: MED-PRIORITY
------------------------------
o Better Spring integration (TX Config)
o Repeating group mapping (solution for n+1 selects problem)
o Inheritance via selects or joins (same as groups)
o Cancel long running statements (cross thread)
o CLOB/BLOB support
o Cross file resource management (currently works, but order dependent --ok?)
o RowSet|ResultSet results?
o Multiple result sets/update results
o Extended configuration logging
o Overriding mapped statements (i.e. reuse SQL; overrides="statementName")
o Cache dependency on other cache (flush-on-dependant)
o Flush cache at specifig time (e.g. 22:30)
o Circular relationships
o Deal with XML as DOM rather than String
------------------------------
FEATURE REQUESTS: LOW-PRIORITY
------------------------------
o Get warnings (conn, ps, rs)
o Type translation filters (e.g. "Y"|"N" -> true|false)
o Pluggable dynamic fragments
o Asynchronous updates (queued)
o Idle Connection Timeout in SimpleDataSource
o Map with 1:M relationship with other Map? (i.e. map key contains list of other maps)
o Per result Lazy Load configuration
o Specify classloader for DAO/SqlMap builders
o Optional results/exclusions (i.e. don't require all results)
o Extended Statements
o Included Statements
o Improved Inline parameters (w/stored proc mode)
xdoclet support would be very nice
I was thinking to use QDox. It's lighter weight than XDoclet and seems to have a simpler API.
From what i can see QDox addresses the specific purpose of parsing the source and extracting various information from the source. Whereas XDoclet has a "code generation" purpose. From looking into the "Who's using it" link on the QDox site it says that XDoclet2 uses Qdox. So, it would seem that if we used QDox we'd be writing some Code Generation functionality that is perhaps taken care of by XDoclet.
But, on a higher level I am curious as to how XDoclet would simplify iBatis development. With the complexities inherent in SQL Mapping, I'm just curious if it really will be that much of a time saver. I'm thinking it will encourage us to place a javadoc attribute in our code that contains a massive sql statement. I understand that you can perform insertions in some way to avoid littering your code with too much "metadata". But, does that really simplify what many are doing now or does it just put the barrier of another "API" to learn in the way. Does it really mandate the use of priority development time?
I don't want to give the impression that I am against XDoclet. I'm simply not clear on how it would be implemented in a way that assists in reducing complexity and increasing productivity.
Could we see some mockup examples/scenarios where it would benefit developers? Would time be best devoted towards creating an IDE plugin that provides a more tailored approach to generating classes/configs for ibatis?
Is it possible to elevate type mapping from low to mid?
Yes...prioritization is also up for discussion.
Yes, XDoclet does a lot more, but also requires a lot more. I like the light weight and low level of QDox. It does just what is needed without overcomplicating everything. I looked at the XDoclet site for about 5 minutes before deciding it was too much. In about 5 minutes on the QDox site, i knew how to use the tool!
As for IDEs, I don't think one replaces the other. I think there is room for both an IDE and an Attribute Oriented Programming solution. I prefer the latter myself, but I think SQL Maps is flexible enough to support a number of development paradigms...including hand coding.
In addition, it seems like Metadata and/or DDL driven solutions are popular already. Although not my personal favourite, I think they're just as valid as any solution.
Lots of fun work ahead!
Clinton
Larry and I discussed this earlier and he brought up a good point. He was thinking the plugins would build upon the attribute programming paradigm rather than work exclusively from a different approach. I think the plugins would allow you to visually map columns to beans, generate beans, basic DAO classes, etc... then it would generate the attributes for you in the class. The plugins would/should be able to also pick up existing attributes and work with them. Also, the attributes generated by the plugins should be usable by a command line option or whatever manner of interacting with the attributes that we build. In that sense QDox sounds like the route I'd prefer to go.
I looked through the forums and the archives and i couldn't find the discussions Clinton and Vic had about DOM. However, (IMO) I dont think we should limit the manner in which the xml can be returned. I think String is a good way to return it myself. Think of all the APIs that may want to use it and all the different way each of those APIs can work with the xml. Dom4j, JDOM, JAXP, JAXB, Castor are just a few. I use dom4j on an app that works with an xml stream and it reads the xml in as a string. So, perhaps we could write a few implementations for the return type of the xml.
As i was looking through the list a bit more seriously I was wondering if some or all these items can be expounded upon.
o Repeating group mapping (solution for n+1 selects problem)
o Inheritance via selects or joins (same as groups)
o Cancel long running statements (cross thread)
o Cross file resource management (currently works, but order dependent --ok?)
o Multiple result sets/update results
o Extended configuration logging
o Get warnings (conn, ps, rs)
o Asynchronous updates (queued)
o Per result Lazy Load configuration
o Optional results/exclusions (i.e. don't require all results)
o Improved Inline parameters (w/stored proc mode)
All will need to be described in more detail. We should probably have a separate thread for each.
Any thoughts on the format/location for the descriptions of these features? We could rely on this forum, or a tracker. We could also have a more formal document with the description of the feature.
Thoughts?
I'm for putting this stuff into the bug/tracker as an ehancement bug and providing the details there. If we know we need to do them at some point then it is the best place for it. If there is brainstorming discussion to be had on it perhaps we can place a link in the bug to a forum thread and discuss the issue in the forum. Once it is concrete or at least firm we can expound by adding new comments in the bug report.
I agree... Having a formal tracking system for bugs is essential. It should also be essential for features.
Using the tracker you can associate features to upcomming versions of the framework. It would effectively eliminate unformal priorities (what does "low-priority" mean?) and would help the development process as a whole...
Also, access to CVS should be one of the features in the list, don't you think?
Regards,
Phil
I'm looking to migrate my antiquated DAO classes with your DAO framework backed by SQL Maps. I expose web services to .NET clients throughout our enterprise, so for 1:M relationships I'm forced to use strongly typed data sets to represent the many-side of a relationship (arrays). Is it possible, to add array types to represent M in 1:M relationships?
"strongly typed data sets" - do you mean you expose a list of beans?
"array types" - do you mean you want the ability to expose something like MyCustomBean[] instead of an Object[] or a List or Beans?
I guess I'm not understanding 100% of what you are asking for.
I apologize for the misunderstanding. I was trying to make a distinction between representing a aggregate relationship as a java.util.Collection and using a BeanType[] array instead. The former being loosely typed from a webservice perspective (how does the webservice consumer know how generate a comparable representation of that Collection), the latter being just an array of beans, which, of course, is supported in SOAP/XML Schema. Being the lone wolf (java) in a den of sheep (.NET), I tend to mix the technologies frequently, hence the world 'data sets' which is used a lot on the .NET side. So the answer to your question is "Yes", I want to be able to populate an array of beans like MyCustomerBean[] instead of a List of Beans using the SQL Maps API.
Thanks,
Lance