Re: Cayenne 4.2—Modifying SQL generation to always use COALESCE when updating a certain column
Hugi Thordarson <[email protected]>
| Newsgroups | gmane.comp.java.cayenne.user |
|---|---|
| Message-ID | <[email protected]> |
First glance at that API looks real nice, I'm going to check this out, thanks :) - hugi > On 11 Sep 2020, at 07:06, Andrus Adamchik <[email protected]> wrote: > > 4.2 for the first time exposes generated SQL as an AST, so tweaking it has become much easier. This is the feature that made possible to support geospatial and JSON types. > > Nikita, please correct me if I am wrong with the following instructions (as this API is still in flux). So.. To customize produced SQL, you will need to register a custom DbAdapter that returns a custom SQLTreeProcessor. SQLTreeProcessor is a SQL tree walking callback that can change the default tree structure. Your own processor can extend TypeAwareSQLTreeProcessor. See for instance PostgreSQLTreeProcessor for how to change the default behavior. > > Andrus > > >> On Sep 8, 2020, at 11:12 PM, Hugi Thordarson <[email protected]> wrote: >> >> Working with old DB designs really results in the weirdest questions… >> >> So… I've been working around a design problem in a customer DB by using my own BatchTranslatorFactory. The functionality was that if a column is called "company", every update wraps the column's new value in a coalesce function to ensure that it's never set to null (for… reasons). This has worked great as a workaround for our problem. >> >> However, SQL generation in Cayenne 4.2 is all new so my current solution ( https://gist.github.com/hugith/a33a20fc7da7fd8f709f59ce3a30a96a <https://gist.github.com/hugith/a33a20fc7da7fd8f709f59ce3a30a96a> ) doesn't really port. >> Before I start considering migration to 4.2, is this possible to do there? Or should I just bite the bullet and start fixing up that bloody DB before upgrading? >> >> Cheers, >> - hugi >