Index re-creation on each DB open

[Lars]

I'm experiencing a strange behaviour with Telerik Data Access and the SchemaHandler CreateUpdateInfo method:

1. I create a new empty DB (SQLite) by using SchemaHandler.CreateDDLScript and ExecuteDDLScript. The DDL already contains indexes for the foreign key columns of associations.

2. I open the new DB and call SchemaHandler.CreateUpdateInfo to check for outdated schema and migration needs.

When the fluent model is unchanged, I'd expect that UpdateInfo.HasScript is false and all its properties are false, too. But in reality UpdateInfo.AddsIndexOnExistingTable is true and the script moves all content of one specific table over to a new identical table and creates the identical indexes again. All in all, a big fat expensive no-op, especially when the DB will be filled.

To me, this seems like a bug. Is it known, is there a workaround?

 

[Lars]

I even get the same result AddsIndexOnExistingTable = true when setting CheckIndex and CheckExtraIndexes to false before calling CreateUpdateInfo. To me, this behaviour doesn't make any sense and breaks any chance for a sensible handling of schema changes using the SchemaHandler.

 

[Boris Georgiev]

Hi Lars,

We are not aware for such an issue in Telerik Data Access and I was not able to reproduce the issue in our test environment using Telerik.DataAccess.Fluent and Core NuGet packages version 2015.3.1221.1.

I have tried to reproduce the issue by defining an index on random column or on the foreign key column but in both cases the script which was generated was null after the update of the database.

Could you describe in more details what is your setup and how you are reproducing the issue always? Could you sent us the sample application and the database script so we could try to reproduce the issue in our test environment?

I am looking forward to hearing from you.

Regards,
Boris Georgiev
Telerik

 

[Lars]

Hi Boris,

I tried hard to reproduce the issue in test code but couldn't. In the end I found out that in the original code the create DDL was cached between sessions. Then, a small change was introduced, changing a property from type int to long, but the DDL was still reused. In the end that resulted in the table including its indexes being migrated. I didn't notice the CAST([SeqNo] AS bigint) in the table migration (since it doesn't make any difference for SQLite) and therefore thought that the indexes were recreated on an identically migrated table w/o change.

I'm very sorry for the confusion and having you try to reproduce the non-problem!

Regards, Lars.

 

[Boris Georgiev]

Hello Lars,

I am glad that you have found the reason of the issue.

If any other questions arise or if you need any assistance with Telerik Data Access do not hesitate to contact us again.

Regards,
Boris Georgiev
Telerik