我使用Symfony(使用FOSUserBundle)和Doctrine从头开始重新开发了一个非常古老的站点。旧站点仍然在线并且在数据库中具有“实时”数据(具有latin1
字符集),并且我试图找出如何将其传输到新数据库(utf8mb4
字符集)。
新网站与我加载到开发数据库Doctrine Fixtures中的虚拟数据配合得很好。但是,例如,对于FOSUserBundle,数据库表具有更多必需参数,其变量如下:
现任成员:
userid
username
email
password
joindt
FOSUserBundle表:
id
username
username_canonical
email
email_canonical
salt
password
然而,我花了整个周末尝试所有不同的方法来复制旧数据库并将其转换为新数据库所需的数据,即从关闭外键生成的PhpMyadmin导出,尝试导出方法,例如:
1a上。 csv文件的不同配置
1b中。在Excel中打开以调整列(例如,复制username
并再次粘贴为username_canonical
)
1c上。将csv文件作为新数据库表导入PhpMyAdmin或删除外键约束并清空新表并读入数据
2a上。 SQL代码
INSERT INTO
步骤CREATE TABLE Member as SELECT username as username, username as username_canonical FROM old
我已经尝试过所有这些的许多共同点,但没有一个有效。我敢肯定,如果我坚持不懈,我将能够拼凑一些东西来生成这个FOSUserBundle Member
表。但是,我担心我会在表格之间的关联中遇到另一个问题而不让我创建其他表格(例如Products
,Orders
)。
一目了然:
答案 0 :(得分:0)
嗯,你有一个大问题。在username_canonical和email_canonical的情况下很简单,因为这些字段只是用户名和没有大写字母的电子邮件,也许其他规则适用(你必须调查),但基本上是这样。真正的问题是密码。我假设在旧数据库中,密码是使用一些不可逆转的算法加密的。 FOSUserBundle的模型是使用注册密码,将其与随机生成的盐连接,使用定义的算法加密整个集合,并保留结果。当请求登录时,激活相同的过程(当然没有生成盐)。因此,如果旧数据遵循相同的注册和身份验证步骤,您可以将处理相应密码和salt字段的旧帐户迁移到新结构,并在新config.yml中设置相同的加密算法,但是如果新数据库需要在其他字符集中,我没有看到可能的迁移解决方案。
如果可以通过明文检索旧密码,您可以设法为新帐户生成所有密码和盐,如果不是这样,我就不会看到迁移方式。也许如果不需要字符集,您可以更改FOSUserBundle以避免生成盐(盐生成防止字典攻击)。 有一种可能的解决方案只保留旧数据库连接用于身份验证,并迁移其余数据,但除了管理两个连接之外,您还有手动确保相关表的参照完整性的问题,但也许如果您有这种可能性是实现目标的唯一途径。