Listing partitioned tables during scaffolding

[Fouz17]

Added support for main partitioned tables during scaffolding.
I have included the virtual table, which is partitioned, but haven't excluded the actual partitions.

Related to issue #2934.

[roji]

Won't this cause a table for each partition to be scaffolded (see comment)?

[Fouz17]

Won't this cause a table for each partition to be scaffolded (see comment)?

True, and currently working on excluding the child tables during scaffolding.

[Fouz17]

Hi @roji, I have finished my work on this, and now child partitions are ignored during scaffolding.
I have also added a test for validating constraints and indexes.

[akillablitz]

Hi @Fouz17 - would it be possible to add a switch parameter to scaffolding to include Children too? We sometimes use partitioning for discriminator TPH type tables... the children have foreign keys to their related tables.. and are currently scaffolding bi directional entity properties... which is desirable. It seems you are about to break this functionality :(

Note other commenters on the linked case are positively using the children partitions too... not sure why the assumption is they are irrelevent / wasteful? #2934

(I also wanted the Parent partition scaffolded too... which you seem to be addressing).

[Fouz17]

Hi @akillablitz , It might be possible to do it that way and I'll have a look into this probably within 2,3 days.

[akillablitz]

Hi @akillablitz , It might be possible to do it that way and I'll have a look into this probably within 2,3 days.

Hi @Fouz17 - just checking in so this doesn't get lost :)

[Fouz17]

Hi @akillablitz , It might be possible to do it that way and I'll have a look into this probably within 2,3 days.

Hi @Fouz17 - just checking in so this doesn't get lost :)

Hi @akillablitz, I looked into the code, and I don't think it is possible to give a flag to include subtables, and the only workaround might be to scaffold all master and child tables

[akillablitz]

Thanks for checking @Fouz17 .

When you say workaround... I am under the impression that your PR will specifically stop scaffolding Child tables, and since we cannot add a command line switch to include them, I will have no work around other than to manually recreate the child entities and their unique relationships in extensibility code... and ensure to keep track of their DDL changes over time.

I'll restate that I'm not sure why there's the hate for child partitions to be treated as noise - only time based partitioning might be considered as such, but that is only one partitioning use case. I'd prefer the change is to include the parent AND the children and let the users decide if they want to use them or not.

[Fouz17]

Thanks for checking @Fouz17 .

When you say workaround... I am under the impression that your PR will specifically stop scaffolding Child tables, and since we cannot add a command line switch to include them, I will have no work around other than to manually recreate the child entities and their unique relationships in extensibility code... and ensure to keep track of their DDL changes over time.

I'll restate that I'm not sure why there's the hate for child partitions to be treated as noise - only time based partitioning might be considered as such, but that is only one partitioning use case. I'd prefer the change is to include the parent AND the children and let the users decide if they want to use them or not.

By work around I meant to include both child and parent tables. I guess we'll need suggestion from @roji

[AbdullahMujtabaKhan]

@roji will this PR be merged?

[roji]

@AbdullahMujtabaKhan I'm currently busy with other things and haven't had time to dive into this.

[JohnYoungers]

Current behavior is, without specifying tables to scaffold, child partitions will be scaffolded without the parent, is that correct?

I would think the best option based on the comments would be to keep that behavior, but now include the parent table as well: I don't think this would be breaking change; consumers that have partitioned tables will now just have additional unused classes.

Alternatively, is there a way to identify if the consumer explicitly opted in (e.g. --table schema.my_parent_table)? If so, including it only in that case may make sense as well: no one should be impacted (although the behavior may be a bit strange).

I think either option is better than having no way to scaffold the parent