Description
Hello,
I tried using the scaffold function to generate my models and then create a migration. However, there seems to be an issue where the generated migration code is incomplete. According to the documentation, it should include a create_hypertable call, but this is missing in my case.
In my setup, the table does not have a Hypertable attribute. Instead, the TimescaleDB-specific configuration is defined in the DbContext class using the Fluent API. Since I couldn’t identify the cause, I created a partial class for the table and added the Hypertable attribute manually, but the migration was still generated without the expected call.
After further investigation, I noticed that the TimeColumnName was set to "timestamp" (the column name). When I changed it to "Timestamp" (the corresponding property name in the generated class), the issue was resolved. After this change, a new migration was generated correctly, including the create_hypertable call.
The same behavior applies when using the Hypertable attribute—it works when referencing the property name instead of the column name.
As this is my first time contributing on GitHub, I hope my description is clear and helpful. My intention is to support by highlighting a potential inconsistency.
Best regards
René Wensing
Steps to reproduce
- Create a hypertable as described here https://www.tigerdata.com/docs/build/how-to/your-first-hypertable
- Scaffold the database as described here https://eftdb.cmdscale.com/docs/dotnet-tools#db-first-scaffolding
- Generate a migration as described here https://eftdb.cmdscale.com/docs/dotnet-tools#code-first-generating-migrations
Expected behavior
I would have expected the scaffolded context and generated classes to be fully compatible with the migration generator without requiring additional adjustments, as this aligns with my intended workflow.
My typical process would be as follows:
- Modify the local database
- Scaffold the database
- Generate a migration
- Apply the migration to multiple database instances
However, I would prefer not to make a determination as to which behavior is correct. At present, there appears to be an inconsistency between the documentation and the implementation.
The documentation indicates that the column name should be used. However, based on the observed behavior of the migration generator, it seems that the property name is expected instead. If this is indeed the intended behavior, then the documentation would need to be updated accordingly, and the scaffolded code may also require adjustment.
.NET version
10.0.107
TimescaleDB version
2.26.3
Eftdb version
10.0.3
Additional context
No response
Description
Hello,
I tried using the scaffold function to generate my models and then create a migration. However, there seems to be an issue where the generated migration code is incomplete. According to the documentation, it should include a create_hypertable call, but this is missing in my case.
In my setup, the table does not have a Hypertable attribute. Instead, the TimescaleDB-specific configuration is defined in the DbContext class using the Fluent API. Since I couldn’t identify the cause, I created a partial class for the table and added the Hypertable attribute manually, but the migration was still generated without the expected call.
After further investigation, I noticed that the TimeColumnName was set to "timestamp" (the column name). When I changed it to "Timestamp" (the corresponding property name in the generated class), the issue was resolved. After this change, a new migration was generated correctly, including the create_hypertable call.
The same behavior applies when using the Hypertable attribute—it works when referencing the property name instead of the column name.
As this is my first time contributing on GitHub, I hope my description is clear and helpful. My intention is to support by highlighting a potential inconsistency.
Best regards
René Wensing
Steps to reproduce
Expected behavior
I would have expected the scaffolded context and generated classes to be fully compatible with the migration generator without requiring additional adjustments, as this aligns with my intended workflow.
My typical process would be as follows:
However, I would prefer not to make a determination as to which behavior is correct. At present, there appears to be an inconsistency between the documentation and the implementation.
The documentation indicates that the column name should be used. However, based on the observed behavior of the migration generator, it seems that the property name is expected instead. If this is indeed the intended behavior, then the documentation would need to be updated accordingly, and the scaffolded code may also require adjustment.
.NET version
10.0.107
TimescaleDB version
2.26.3
Eftdb version
10.0.3
Additional context
No response