在 after_create 回调期间无法获取外键，因为它还不存在！
我有一些模型在内存中全部链接在一起（父：子：子：子），并通过保存最顶层的父项同时保存。这很好用。
我想利用其中一个子级的 after_create 回调来填充更改日志表。我需要复制/推送到更改日志表中的属性之一是子级到其直接父级的外键，但在 after_create 触发时它不存在！？！
如果没有 after_create 回调，我可以查看日志并看到子级在其父级（外键空白）之前被保存，然后插入父级...然后使用 id 更新子级来自父母。子进程的 after_create 在正确的时间触发，但它发生在 Rails 有机会使用foreign_key 更新子进程之前。
有什么方法可以强制 Rails 以某种顺序保存模型的这种链接吗？即.parent，然后是child（父foreign_key存在），然后是该child的child（同样，foreign_key是可访问的）等。如果没有，在创建记录并获取foreign_key后我将如何触发例程？
似乎这样的回调会很有帮助：after_create_with_foreign_keys
I have some models all linked together in memory (parent:child:child:child) and saved at the same time by saving the top-most parent. This works fine.
I'd like to tap into the after_create callback of one of the children to populate a changelog table. One of the attributes I need to copy/push into the changelog table is the child's foreign_key to it's direct parent, but it doesn't exist at the time after_create fires!?!
Without the after_create callback, I can look in the log and see that the child is being saved before it's parent (foreign key blank) then the parent is inserted... then the child is updated with the id from the parent. The child's after_create is firing at the right time, but it happens before Rails has had a chance to update the child with the foreign_key.
Is there any way to force Rails to save such a linkage of models in a certain order? ie.parent, then child (parent foreign_key exists), then that child's child (again, foreign_key is accessible) etc. ?? If not, how would I have my routine fire after a record is created AND get the foreign_key?
Seems a callback like this would be helpful: after_create_with_foreign_keys
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于我在内存中构建所有关联的模型，并在保存最顶层父级时依赖 Rails 来保存所有内容，因此我无法利用 after_create 回调并利用外键（对于 Change_log 表条目），因为Rails 保存模型的顺序。所有内容总是以正确的方式连接，但有时会先保存子记录，然后保存父记录，然后会更新子记录以插入parent_id。
我的解决方案是不在内存中构建模型，放弃一次性保存所有内容的想法。相反，我会保存最顶层的模型，然后通过该父级的 after_create 创建其子级。然后，该孩子的 after_create 将创建其孩子，依此类推。我更喜欢这种安排，因为我可以更好地控制与外键相关的回调。最后，整个事情被包装在一个数据库事务中，以便在出现严重错误时撤消任何插入。这是我在内存中构建所有内容的最初原因，因此在保存之前我会将所有鸭子排成一排。模型/数据库事务减轻了担忧。
Since I was building all my associated models in memory and relying on Rails to save everything when I saved the top-most parent, I couldn't tap into the after_create callbacks and utilize a foreign key (for a change_log table entry) because of the order in which Rails would save the models. Everything always ended up connected in the proper way, but sometimes a child record would be saved first, then the parent, then an update to the child record to insert the parent_id would happen.
My solution was to not build my models in memory, abandoning the idea of saving everything in one fell swoop. Instead, I would save the top-most model and then create its child via the after_create of that parent. That child's after_create would then create its child and so on. I like this arrangement much better as I have more control over my callbacks in relation to foreign keys. Lastly, the whole thing was wrapped in a db transaction so as to undo any inserts if something went horribly wrong along the way. This was my original reason for building everything in memory, so I'd have all my ducks in a row before saving. Model/db transactions alleviates the worry.
您可以在parent_id可用后使用
after_update来捕获子进程吗？当after_update触发时，parent_id 将可用，因此如果子项不在表中，请将其插入。Could you use
after_updateto catch the child after the parent_id is available? Whenafter_updatefires, the parent_id will be available, so if the child is not in the table, insert it.