Hi Mark, Can we:
1.a Have an inner static class in DBDic to load the reserverd keywords once for all? 1.b Keep keyword configuration working to enable to use custom reserved keywords (ie add reserved keywords in the unit properties) 2. Maybe move the reserved keyword resource per dictionary with a specific "openjpa-default" keyword which means load the shared file too? This is really a per DB config and shared one can only cover a subpart of the actual list. 3. Are we able to list the diff and potentially to toggle a fallback on previous generation (don't want an "update schema" strategy breaks the DB/app). About the missing values: the issue is that it can not be missing in older versions so we can need a way to enable them or a subdic impl which enable them OOTB (for ex MySQL7Dic extends MySQL5Dic and the related openajp/sql-mysql7-keywords/reserved-names.rsrc), no? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 31 mars 2021 à 09:40, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > Hi folks! > > Yesterday I did a lot of work on the DBDictionary Column name handling. > I've experienced a few issues when running our test suite against MS > SQLServer, and then found a few very old bugs in our issue tracker. > > I probably gonna change the logic slightly once again to make it even more > configurable. > > There is a list of reserved SQL keywords > > https://www.drupal.org/docs/develop/coding-standards/list-of-sql-reserved-words > < > https://www.drupal.org/docs/develop/coding-standards/list-of-sql-reserved-words > > > > I fear this is not a perfect list, and many databases might be ok with a > subset of it as column names. E.g. while TYPE is on the list of reserved > words it is a perfectly valid column name in some databases. > > The new logic is as following: > 1. load all the reserved standard keywords (old list we maintained > ourselves in the past) from 'sql-keywords.rsrc'. This file is really old > (initial checkin from Patrick, it was already part of KODO). > In the old days this was only done in endConfiguration(). But this is way > too late, as some DBDicts did use it as base for their > invalidColumnWordSet. At the point this list was used it was always empty, > leaving some DBDicts effectively without any reserved words. Thus I moved > the sql-keywords.rsrc loading to the ct. > > 2. Some DBDictionaries do maintain their own list of both lists (reserved > words and reserved column names), e.g. > > https://github.com/apache/openjpa/blob/aeb333fb3a6b7eb611c3ed79ba39c6286445f5b3/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/OracleDictionary.java#L214 > < > https://github.com/apache/openjpa/blob/aeb333fb3a6b7eb611c3ed79ba39c6286445f5b3/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/OracleDictionary.java#L214 > > > Manually setting those will always take precedence over sql-keywords.rsrc > and sql-invalid-column-names.rsrc loading (a new file I did introduce > yesterday). The later will only be loaded if the database did not define > any invalid column names. > > 3. I fixed ColumnDefIdentifierRule. It actually was never used it seems. > And it in turn did not use the invalidColumnWordSet defined in the > DBDictionary. This now works. I tried to be as sensible as positive, but it > might mean that we gonna see some slight difference in column name > generation. > > > We also miss a list of really tested reserved column names. Probably we > should do a test where we try to create all of them and then collect those > to a file? > Anyone here who likes to hack such a small tool? t could use the databases > provided via our docker setup as documented here: > > https://github.com/apache/openjpa/blob/master/README.adoc#testing-against-different-databases > < > https://github.com/apache/openjpa/blob/master/README.adoc#testing-against-different-databases > > > > LieGrue, > strub > > >
