Hmm, code looks wrong anyway since https://github.com/apache/openjpa/blob/dd9bce0cc909bd96d706a9438bdc2a58111c481f/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/identifier/DBIdentifierUtilImpl.java#L286 handles delimiter now so shouldnt be handled twice probably.
> The problem is that it only creates a problem if you let this run multiple times Does it mean when a DB exists and you restart the app (or another instance starts) problem accurs? This must clearly not be I agree. 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 mar. 4 mai 2021 à 11:53, Enrico Olivelli <eolive...@gmail.com> a écrit : > Il giorno mar 4 mag 2021 alle ore 11:19 Mark Struberg > <strub...@yahoo.de.invalid> ha scritto: > > > > Hi! > > > > > https://github.com/apache/openjpa/commit/dd9bce0cc909bd96d706a9438bdc2a58111c481f > < > https://github.com/apache/openjpa/commit/dd9bce0cc909bd96d706a9438bdc2a58111c481f > > > > > > The problem is that it only creates a problem if you let this run > multiple times. PostgreSQL internally converts all delimited columns to > lowercase. But somewhere along the way it corrupted the information, > leading to some columns not being able to allow dropping the whole table > due to not matching anymore. > > > > The problematic area seems to be this code part. It does not look wrong, > but somehow it creates a problem with PostgreSQL: > > > > protected Column addPrimaryKeyColumn(Table table) { > > DBDictionary dict = _conf.getDBDictionaryInstance(); > > DBIdentifier delimitedColumnName = > dict.fromDBName(getPrimaryKeyColumn(), > DBIdentifier.DBIdentifierType.COLUMN); > > Column pkColumn = table.addColumn(dict.getValidColumnName > > (delimitedColumnName, table)); > > > > previously (and now again) it was: > > Column pkColumn = > table.addColumn(dict.getValidColumnName(getPrimaryKeyColumnIdentifier(), > table)); > > > > Happy to help with HerdDB, but stability for existing databases must be > guaranteed. > > > I have run a minimal set of tests on HerdDB with current OpenJPA > master and my tests are passing. > > ButI am sure that I did those changes for some reason, probably for > the tests we were running with Romain in preparation to ApacheCon. > I cannot find them anymore (I changed my laptop/work in the meantime). > > Probably the problem was about recreating the > tables/columns/sequences, like the problems you are pointing out with > PGSQL > > Enrico > > > Let's try to work this out till the weekend! > > > > LieGrue, > > strub > > > > > > > > > Am 04.05.2021 um 08:52 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > > > > Hi, > > > > > > The HSQLDB changes are okish and does not break existing applications > > > (which is the most important) so only people working on generated DDL > > > directly can have issues and due to the actual impact it should be fine > > > anyway. > > > > > > However, breaking HerdDB is not an option so I agree with Enrico we > should > > > ensure it works - at least as HSQL where the runtime is not broken - or > > > delay the 3.2 until we can do it. > > > > > > @Mark did you see why we didn't catch these issues before since build > was > > > green when we merged HerdDB integration? Is it profile related (and > should > > > we enable them by default with N surefire executions) or something not > > > covered we should add? Goal is indeed to avoid it to happen again. > > > > > > 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 mar. 4 mai 2021 à 08:47, Enrico Olivelli <eolive...@gmail.com> a > écrit : > > > > > >> Il giorno mar 4 mag 2021 alle ore 08:24 Mark Struberg > > >> <strub...@yahoo.de.invalid> ha scritto: > > >>> > > >>> hi folks! > > >>> > > >>> We are nearing a release. We just have to polish the documentation > and > > >> prepare. > > >>> > > >>> I've successfully did run all tests green for the following > databases: > > >>> > > >>> * Derby > > >>> * h2 > > >>> * PostgreSQL > > >>> * Oracle > > >>> * MySQL > > >>> * MariaDB > > >>> * MS SQLServer > > >>> > > >>> * Hypersonic (HSQLDB) has a few test glitches since many moons :( > > >> Nothing tragical, only things like missing delimiters when > DBIdentifiers > > >> has spaces, etc. We need to work on it, but I fear it will not be > ready for > > >> this release. Same tests have been failing for the last releases as > well. > > >>> > > >>> I had to revert a few delimiter changes which came as part of the > HerdDB > > >> support. > > >> > > >> Can you please point out what has been reverted ? > > >> I believe Romain had some test case applications that break due to > > >> reserved Words. > > >> > > >> I am sorry that I did not have time to complete the work on making all > > >> tests pass on HerdDB. > > >> > > >> We need to do a general re-evaluation of DBDictionary#delimitAll. This > > >> needs more time and we must make sure it breaks no other existing > > >> databases. Not sure if we can find time before 3.2.0 or rather fix it > > >> for 3.2.1 and only ship preliminary support for HerdDB for now? > > >>> > > >>> Any opinions? > > >> > > >> I can try to build current Master and run the few tests cases we have > > >> in HerdDB repo that test compatibility with OpenJPA > > >> > > >> Enrico > > >> > > >>> > > >>> txs and LieGrue, > > >>> strub > > >> > > >
