首先使用EF代码(Devart Connector)创建的数据库中的数据迁移到EFCORE代码(SQLITE)

发布于 2025-01-24 09:03:21 字数 718 浏览 4 评论 0原文

EFCORE文档非常具体地在做什么方面,将基于EF的代码库迁移到efcore https://learn.microsoft.com/en-us/ef/ef/efcore-and-yef6/porting/ 。但是,我找不到有关如何将存储在SQLite数据库中的数据从EF到EFCORE中的建议。

除了从旧的EF DBContext阅读并写入新的EFCORE上下文的明显方法之外,我们还在探索配置EFCORE的可能性(使用相同的模型类)以创建由EF创建的相同数据库架构,然后将EFCORE DBCONTEXT创建为阅读数据。

这种方法是迁移数据还是继续从旧模式访问数据的建议方法?

EF创建的架构和EFCORE困扰我似乎存在多种差异。其中一些可能与以下事实有关,即使用EF,我们使用了Devart dotConnect数据提供商,而使用EFCORE,我们使用EFCORE项目随附的数据库提供商。

这导致了GUID的不同表示形式,被宣布为EF中的GUID和EFCORE文本。同样,外键的名称生成似乎是不同的,而EF生成的名称(如property_id for Resseigonne for for Resseion efcore似乎都会创建property ID。

The EFCore documentation is very specific on what to do, to migrated an EF based codebase to EFCore https://learn.microsoft.com/en-us/ef/efcore-and-ef6/porting/ . However, I could not find advice on how to bring the data stored in an sqlite database from EF to EFCore.

Beside the obvious approach to read from the old EF dbcontext and write to the new EFCore context, we are exploring the possiblity to configure EFCore (using the same model classes) to create the same database schema created by EF and then use the EFCore dbcontext to read the data.

Is this approach the recommended way to migrate the data or continue accessing the data from the old schema?

There appear to be multiple differences in the schema created by EF and EFCore troubling me. Some of them might be related to the fact that with EF we used Devart dotConnect Data Provider while with EFCore we use the database provider that comes with the EFCore project.

This leads to different representations of Guid being declared as Guid in EF and TEXT in EFCore. Also the name generation for foreign keys appears to be different, while EF generated names like Property_Id for relationships EFCore seems to create PropertyId instead.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

如此安好 2025-01-31 09:03:21

首先,我将以倒转工程您现有的SQLITE数据库到EF核心模型。这将为您提供一个很好的起点。

不幸的是,由于SQLITE只有四种原始类型,您的模型将仅包含longStringdoublebyte [] byte [] 属性(upvote essue #8824 以改进这一点)。

因此,下一步将是修复模型中的类型,以返回以前使用的类型。执行此操作时,请保持默认类型映射在心中。

正如您注意到的那样,某些类型GUID默认情况下可能会映射到其他类型。您可以使用ef core 值转换以补偿这些差异。例如,这是将所有guid值映射到blob的方法。

// ...in your DbContext...

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Properties<Guid>().HaveConversion<byte[]>();
}

First, I'd start by reverse engineering your existing SQLite database to an EF Core model. This will give you a good starting point.

Unfortunately, because SQLite only has four primitive types your model will only contain long, string, double, and byte[] properties (Upvote issue #8824 to improve this).

So, the next step will be to fix the types in your model to go back to the ones you were using before. When doing this, keep the default type mappings in mind.

As you noticed, some types like Guid may map to a different type by default. You can use EF Core value converts to compensate for these differences. For example, here's how to map all Guid values to BLOB.

// ...in your DbContext...

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Properties<Guid>().HaveConversion<byte[]>();
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文