Saurabh Nanda

Does Jailer have a feature which sets sequences to the curr_val in the original database, at the end of the export script?

Thanks for the detailed response, Ralf. If the .jm file already contains a list of known associations, is the datamodel/<dbname> folder really needed during an export? If yes, would it be possible to point me to some docs on how to re-run the "analyze database" process via the commandline (assuming that it won't lose the manually added associations, as you mentioned above).

Hi, I'm planning to use Jailer to export a subset of our production data [1], so that it can be loaded into our testing/CI environments. I've got a jailer data-model setup via the GUI and it works pretty well for the current database schema. How do I ensure that this continues to work as our database schema evolves over time? IIUC, the files at play are the following: the .jm config file one folder inside the datamodel folder, i.e. datamodel/<dbname> The datamodel/<dbdname> folder looks like it contains...

I solved this in a very different manner. I disabled all child relationship for the topmost/root table. I'm exporting them as additional-subjects instead.

Does this help? https://gist.github.com/saurabhnanda/027311d11f6e2441cfa2c62b6878baee

There is no non-nullable FK in 'form_ulator_custom_forms'. I think the problem is being narrowed down. You are right, the client_id field is indeed nullable in the schema, however there is this CHECK CONSTRAINT... "client_not_null" CHECK (channel_custom_form OR client_id IS NOT NULL) ...which is ensuring that either channel_custom_form=true OR client_id is not null Is this what is confusing jailer? How can I change the model definition to handle this case?

Any clues on how to debug this?

The file you've sent me doesn't have rows where created_at is NULL. Does the problem still occur? I have mentioned in comments at the very bottom -- I remember seeing created_at being exported as NULL, as well, but it didn't happen in this particular run of the export. However, you can see that one of the non-nullable FKs is indeed NULL even in the SQL file I shared with you.