Hello Sergey, > 1. At this moment Record.from copies values from bean to record and does all > value "changed". > For example, we read fresh record from database and apply changes using > Record.from from some bean. > After that all fields including primary key marked as "changed" and > Record.store tries to insert record instead of update. > Is it reasonable copy only different values?
Nice hint. I'll think about this. I agree that the primary key (or "main unique key") shouldn't be flagged as changed for the reasons you mentioned. I think this is checked elsewhere, already. For the other fields, it might be good to set them in updates as well, though: 1. to avoid potentially stale values not being set 2. to increase performance because of fewer soft-parses in the DB. There will be only one possible UPDATE statement per table, instead of O(n^2) for all combinations of changed fields. I'll file this as https://sourceforge.net/apps/trac/jooq/ticket/979 It'll be included in 2.0.1 > 2. FactoryProxy creates new instance of Factory for each request. So > QueryParts created from different threads should reference different Factory > (Configuration) instances.. Perfect. Then you should be safe. Cheers Lukas 2011/12/6 Sergey Epik <[email protected]>: > Hello Lukas, > > 1. At this moment Record.from copies values from bean to record and does all > value "changed". > For example, we read fresh record from database and apply changes using > Record.from from some bean. > After that all fields including primary key marked as "changed" and > Record.store tries to insert record instead of update. > Is it reasonable copy only different values? > > Here is possible change in Util.setValue: > > static final <T> void setValue(Record target, Field<T> targetField, > Object value) { > T newValue = targetField.getDataType().convert(value); > T oldValue = target.getValue(targetField); > boolean equals = (newValue != null && newValue.equals(oldValue)) || > (newValue == null && oldValue == null); > if (!equals) { > target.setValue(targetField, > targetField.getDataType().convert(value)); > } > } > > 2. FactoryProxy creates new instance of Factory for each request. So > QueryParts created from different threads should reference different Factory > (Configuration) instances.. > > Best regards, > Sergey > > > > On Mon, Dec 5, 2011 at 10:19 AM, Lukas Eder <[email protected]> wrote: >> >> Hi Sergey, >> > Please find in attacment latest FactoryProxy and simple unit tests, >> > that> demonstrate usage of jOOQ in spring container.> You can find that >> > FactoryProxy does not depend on Spring at all, it just> provide thread safe >> > access to factory operations.> Transaction aware data source manages >> > connection (takes it from target> datasource, binds connection to the >> > current thread, closes connection) , so> it's important that code should be >> > intercepted by transaction manager. >> Hmm, maybe at this point I need to warn you that QueryParts created >> from a Factory are not thread-safe either. They are "attached" through >> the org.jooq.Attachable interface. You shouldn't use the same >> org.jooq.Query instance in different threads, or their underlying >> factories / connections might get mixed up! >> I'm having a closer look at your updated jOOQ-spring project and your >> links later >> >> Cheers >> Lukas >> 2011/12/4 Sergey Epik <[email protected]>: >> > Hello Lukas, >> > >> > Please find in attacment latest FactoryProxy and simple unit tests, that >> > demonstrate usage of jOOQ in spring container. >> > You can find that FactoryProxy does not depend on Spring at all, it just >> > provide thread safe access to factory operations. >> > Transaction aware data source manages connection (takes it from target >> > datasource, binds connection to the current thread, closes connection) , >> > so >> > it's important that code should be intercepted by transaction manager. >> > >> > Test cases are inspired by tests from querydsl-spring integration. >> > Here is example of usage querydsl-spring: >> > >> > https://github.com/SpringSource/spring-data-jdbc-ext/blob/master/spring-data-jdbc-core/src/test/java/org/springframework/data/jdbc/query/QueryDslCustomerDao.java >> > I am not sure that integration with JdbcTemplate is a perfect solution. >> > It >> > can give some benefits: >> > - connection is released to the pool after query execution (connection >> > may >> > be reused for other tasks) >> > - mapping SQLException codes to exception hierarchy ( >> > >> > http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/dao/package-summary.html >> > ), it's possible to provide custom SQLErrorCodesTransalator. >> > I think that much better to add this features to jOOQ in the future, >> > than >> > integrate jOOQ with low level JdbcTemplate API. >> > >> > Fell free to remove jooq-spring or to move it to some "sandbox", as >> > example. >> > >> > -- >> > Best regards, >> > Sergey >> > >> > >> > On Fri, Dec 2, 2011 at 11:05 AM, Lukas Eder <[email protected]> >> > wrote: >> >> >> >> Hi Sergey, >> >> >> >> I just realised: I haven't mentioned the jOOQ-Spring SVN project yet. >> >> Neither did I release it officially. The reason is, I'm not sure if >> >> the current jOOQ-Spring is general enough for broad usage. To me, it >> >> leaves a lot of open questions about how to use it, how to document >> >> it, etc. I guess I would need to see it in action, first...? If I >> >> should officially support such an extension, then I'll need ideas >> >> about how to integration-test it, and extend it in future >> >> developments. >> >> >> >> Note, jOOQ-Wicket was a similar contribution, which I never released >> >> so far, for the same reasons. >> >> >> >> Cheers >> >> Lukas >> >> >> >> 2011/11/27 Lukas Eder <[email protected]>: >> >> > This release is a fresh start in many areas of jOOQ, adressing >> >> > issues that have been requested by users for a long time. These >> >> > release notes document the most important changes, a detailed >> >> > upgrade guide, as well as the detailed list of improvements. >> >> > >> >> > For full details, please visit the release notes page: >> >> > http://www.jooq.org/notes.php >> >> > >> >> > Most important changes >> >> > ---------------------- >> >> > - The API became more static. This applies to many Factory >> >> > methods, such as val(), literal(), as well as to many Field >> >> > methods that have been moved over to the Factory. For example, >> >> > when before, you wrote this using "postfix function notation": >> >> > >> >> > <pre>NAME.replace(" ", "_").trim()</pre> >> >> > >> >> > you will now write (just as in SQL): >> >> > >> >> > <pre>trim(replace(NAME, " ", "_"))</pre> >> >> > >> >> > Using static imports of Factory.*, jOOQ makes SQL look even >> >> > more like SQL. The current "postfix notation" is maintained for >> >> > backwards compatibility. >> >> > >> >> > - By default, jooq-codegen will now generate a "dynamic" meta >> >> > model as opposed to the existing static one. Generated tables >> >> > covariantly override the as(String) aliasing method, leading >> >> > to a much more convenient aliasing style. When before, you >> >> > wrote: >> >> > >> >> > Table<TRecord> parent = T.as("parent"); >> >> > Table<TRecord> child = T.as("child"); >> >> > Condition join = >> >> > parent.getField("ID").equal(child.getField("PARENT_ID")) >> >> > >> >> > You can now write: >> >> > >> >> > T parent = T.as("parent"); >> >> > T child = T.as("child"); >> >> > Condition join = parent.ID.equal(child.PARENT_ID) >> >> > >> >> > Of course, the existing notation still works >> >> > >> >> > - Exceptions are no longer checked. When previously, the DB's >> >> > SQLException was propagated to client code, there is now an >> >> > unchecked DataAccessException hierarchy, similar to that of >> >> > Spring. This will eventually give way to a standardised error >> >> > handling abstraction, in future developments >> >> > . >> >> > - Window functions are now constructed from their underlying >> >> > aggregate functions just like in SQL. For example: >> >> > >> >> > sum(AMOUNT) >> >> > sum(AMOUNT).over().partitionBy(ACCOUNT) >> >> > >> >> > This makes for a more concise API, especially when considering >> >> > future extensions, such as Oracle's KEEP (DENSE_RANK FIRST...) >> >> > syntax. >> >> > >> >> > - More type safety has been introduced regarding various places >> >> > where generic <R extends Record> and <T> types are involved. >> >> > This is especially true for INSERT / UPDATE / DELETE statements >> >> > >> >> > - Sequences now also have a <T> type >> >> > >> >> > - Unsigned number types are now supported in those databases that >> >> > use them. Unsigned numbers are implemented in jOOU, a spin-off >> >> > open source project. For convenience, this library is >> >> > "internalised" into jOOQ, to avoid adding a dependency >> >> > >> >> > http://code.google.com/p/joou/ >> >> > >> >> > Upgrade instructions: >> >> > --------------------- >> >> > Various of the above changes are incompatible with jOOQ 1.x. In >> >> > order to upgrade, please be aware of the following pitfalls: >> >> > >> >> > - The schema needs to be re-generated. >> >> > >> >> > - Much of the post-fix function notation is replaced by static >> >> > methods in the Factory. Today's org.jooq.Field API is >> >> > maintained in jOOQ 2.0, for backwards compatibility. It will >> >> > be removed, eventually, though. Expect some incompatible >> >> > changes, where window functions are involved >> >> > >> >> > - Some Factory instance methods (such as val(), literal()) are >> >> > now static. They are compatible, but may cause compiler >> >> > warnings. >> >> > >> >> > - The meta model is now an instance model by default. If you >> >> > prefer the static meta model, you can configure this in your >> >> > jooq-codegen configuration. >> >> > >> >> > - The additional typesafety involving <R> and <T> types may cause >> >> > compiler warnings and errors. >> >> > >> >> > - SQLException is no longer part of the API. This can cause >> >> > compiler issues, in particular when extending jOOQ >> >> > >> >> > - Some utility classes have moved to org.jooq.tools >> >> > >> >> > Should these incompatibilities be too significant for your >> >> > project, you can still stay on the 1.x branch, which will be >> >> > maintained for a while. Be aware that upgrading might be more >> >> > difficult, later, though. >> >> > >> > >> > > >
