Due to company policy, unfortunately, I can't simply just upload the DDL of the schema that caused the issues. So, I tried to recreate the relationships to reproduce the errors. I tried up to 30 tables, generated in various ways to try to mimic the error. No dice. So, it seems the complexity of the schema plays a role in the generation error. I will continue to try to find a minimal set of tables that will produce the issue consistently.
This error is not universal, meaning that it does not happen for all tables, only a select few. In the over 300 tables in the schema that I have, I have this error for around 20 tables. The code generated for the rest is fine, using the right primary key. There must be a common pattern for these 20 odd tables. Unfortunately, I can't find the common pattern yet. Once I find it, I should be able to come up with a minimal set. Then I will file the report.
--
Then, I decided to "correct" the errors with a script so that I could continue the investigation on whether the code generated would be useful for my purpose. After the "corrections", the code compiles. To my surprise, after doing the changes, I have no access to the primary and foreign keys of the generated table classes any more. So, ABC.ABC_ID is now a private field. Which is fine, I guess, but I don't know how to compare keys in a join as I don't see a field that is public that I can use. I am quite sure I am just ignorant of the right way to do updates, inserts, and joins once I decide to have the embedded keys generated. I will try to find out what is the new ways to do these operations with the code generated being rather different from before. However, to have to change all the occurrences of how keys are used for all the tables in all the places in our system might be a time-consuming task. This can't be correct, right? Correcting the comparison where one side is a Integer or a String or what have you is fine, as that is the whole point of having one type for each key. They are also mostly in the WHERE clause as well. Not being to compare ABC.ABC_ID and EFG.ABC_ID is a bit different, as this is pervasive wherever I have a join.
I would appreciate it very much if I can be pointed to the section of the documentation where it talks about how keys are used once I have these private key fields.
So, I had this before, for example:
create.select()
.from(ABC)
.join(EFG).on(ABC.ABC_ID.equal(EFG.ABC_ID))
.where(ABC.NAME.equal("Smith"))
.fetch();
Now it would say ABC_ID is a private field (back to the error I got when I tried to generate code for the indexes), which it is. My problem is that I don't know what to substitute ABC_ID with.
Thanks in advance for any insight into how these DML should now be constructed!
My learning continues, of course, this being my second day after subscribing to the express edition.