Got it. Will see when and how we can refactor the existing code base to fit this.
Thanks. On Friday, March 1, 2024 at 4:34:14 AM UTC-5 [email protected] wrote: > On Thu, Feb 29, 2024 at 8:30 PM Khun Yee Fung <[email protected]> wrote: > >> 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. >> > > I understand. Thanks a lot for looking into this. I'll continue checking > on my side how this could happen. My main hypothesis is that there's a > naming problem of the embeddable column, i.e. the table where the > embeddable key is declared uses a different name for the embeddable than > the reference in the generated record. Can you confirm this is the case? > But that wouldn't explain yet why this happens. > > >> 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. >> > > Embeddable keys automatically apply "field replacement": > > https://www.jooq.org/doc/latest/manual/code-generation/codegen-embeddable-types/codegen-embeddable-types-replacing-fields/ > > The point is that you will never want to compare individual fields of an > embeddable key anymore. You will always want to treat the embeddable key as > a whole. So, rather than comparing ABC.ABC_ID and EFG.ABC_ID individually, > you will compare ABC.KEY and EFG.KEY (or whatever they're called). This > improves type safety of your queries, as you can't compare any BIGINT > columns randomly anymore, for example. > > Can you show an example schema and query where you still need access to > the underlying columns? Perhaps we should add another flag to allow for > opting out of this code generation behaviour, though I do believe this is > the right default, and what most people want. The main reason why > embeddable keys were implemented was precisely this, people were asking for > a domain type per key, to get the added type safety. > > I hope this helps > Lukas > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/1fd7f95f-6bef-4cff-9ec0-ecec8319ed42n%40googlegroups.com.
