Failed to generate migrations

[Z2Flow]

I have a schema generated by a visual modelling tool (DbSchema) and in generating migrations The Brick listed these errors:

Can't do devices because: premise_bt Can't do inspections because: inspector_bt, test_kit_bt, device_bt Can't do inspectors because: account_user_bt Can't do premises because: premise_manager_bt Can't do test_kits because: inspector_bt DbSchema has a cyclic dependency checker and it came up empty—no errors. I'm at a loss as to why The Brick failed these tables. Are there conditions, other than cyclic dependencies, that cause failures?

[lorint]

Are there conditions, other than cyclic dependencies, that cause failures?

There shouldn't be ... Often when this kind of thing surfaces, omitting just one table can cause the whole thing to complete, and then separately you can try adding a migration for that one table.

In this case you might want to first try omitting the top-listed entry -- premise_bt. Brick sequences the tables mentioned in the order of "connectedness", so it is most likely that those at the top are impacting things.

If that doesn't fly then second try omitting inspector_bt becuause that one is mentioned twice.

If you are OK to share the schema with me then I'd be curious to look through the structure and understand more. A set of DDL statements -- a bunch of CREATE TABLE -- is good, or just the schema.rb itself. Totally understand if this is not possible -- many systems out there are proprietary!

Thanks so much for reaching out, Rob -- curious to hear how this adventure progresses!

-Lorin

[Z2Flow]

Hi Lorin,

Got sidetracked with an urgent issue, but back now.

Thanks for getting back to me.

I deleted the FK premise_bt and the migrations produced this:

Can't do account_addresses because: municpal_office_bt, municipality_bt Can't do inspections because: inspector_bt, test_kit_bt Can't do inspectors because: account_user_bt Can't do municipalities because: contact_bt Can't do premise_owners because: contact_bt, address_bt Can't do premises because: contact_bt, address_bt, premise_manager_bt, premise_owner_bt Can't do test_kits because: inspector_bt

Then I deleted inspector_bt and got this:

Can't do inspections because: test_kit_bt Can't do inspectors because: account_user_bt Can't do test_kits because: inspector_bt

I’ve attached the schema ddl before the FK deletions, and also a diagram of the model.

I look forward to hearing from you .

Cheers, Rob

On 10 Oct 2023, at 18:12, Lorin Thwaits @.***> wrote:

Are there conditions, other than cyclic dependencies, that cause failures?

There shouldn't be ... Often when this kind of thing surfaces, omitting just one table can cause the whole thing to complete, and then separately you can try adding a migration for that one table.

In this case you might want to first try omitting the top-listed entry -- premise_bt. Brick sequences the tables mentioned in the order of "connectedness", so it is most likely that those at the top are impacting things.

If that doesn't fly then second try omitting inspector_bt becuause that one is mentioned twice.

If you are OK to share the schema with me then I'd be curious to look through the structure and understand more. A set of DDL statements -- a bunch of CREATE TABLE -- is good, or just the schema.rb itself. Totally understand if this is not possible -- many systems out there are proprietary!

Thanks so much for reaching out, Rob -- curious to hear how this adventure progresses!

-Lorin

— Reply to this email directly, view it on GitHub https://github.com/lorint/brick/issues/10#issuecomment-1756340059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ5VGA4VULOFHYO6YMK3D23X6XB3XAVCNFSM6AAAAAA5257TL2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJWGM2DAMBVHE. You are receiving this because you authored the thread.



[lorint]

I’ve attached the schema ddl before the FK deletions, and also a diagram of the model.

Unfortunately it doesn't look like the "remailer" added any of the attachments -- feel free to send them directly to me at lorint@gmail.com.

Fun to play with these kinds of things!

-Lorin