Schema tool doesn't play well with metadata caching #5798

Closed
opened 2026-01-22 15:18:15 +01:00 by admin · 4 comments
Owner

Originally created by @martixy on GitHub (Dec 11, 2017).

Originally assigned to: @lcobucci on GitHub.

I was making changes to my model and had created a new entity, and was using the schema tool to dump the raw SQL.

I spotted a small mistake in my definition and after fixing it and dumping again, the change wasn't reflected.
Eventually I discovered that when you have metadata caching, only the first version of any new entity is recognised. Thereafter, no matter what changes you make to your entity, the schema tool not reflect those, since it has now cached the first version, and that's all it knows.

Given the function of this tool, would it not be better to force it to bypass caching altogether?

Originally created by @martixy on GitHub (Dec 11, 2017). Originally assigned to: @lcobucci on GitHub. I was making changes to my model and had created a new entity, and was using the schema tool to dump the raw SQL. I spotted a small mistake in my definition and after fixing it and dumping again, the change wasn't reflected. Eventually I discovered that when you have metadata caching, only the first version of any new entity is recognised. Thereafter, no matter what changes you make to your entity, the schema tool not reflect those, since it has now cached the first version, and that's all it knows. Given the function of this tool, would it not be better to force it to bypass caching altogether?
admin added the BugInvalid labels 2026-01-22 15:18:15 +01:00
admin closed this issue 2026-01-22 15:18:16 +01:00
Author
Owner

@Ocramius commented on GitHub (Dec 11, 2017):

No - the schema tool just receives metadata: whether that requires cache
invalidation or not is to be decided on a case-by-case basis.
It is a generic tool and it should stay as such.

On 11 Dec 2017 19:00, "Martin Ninov" notifications@github.com wrote:

I was making changes to my model and had created a new entity, and was
using the schema tool to dump the raw SQL.

I spotted a small mistake in my definition and after fixing it and dumping
again, the change wasn't reflected.
Eventually I discovered that when you have metadata caching, only the
first version of any new entity is recognised. Thereafter, no matter what
changes you make to your entity, the schema tool not reflect those, since
it has now cached the first version, and that's all it knows.

Given the function of this tool, would it not be better to force it to
bypass caching altogether?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6876, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakC6YMXWjjKuR895Hz5I6ujfKbkDjks5s_W2qgaJpZM4Q9zJF
.

@Ocramius commented on GitHub (Dec 11, 2017): No - the schema tool just receives metadata: whether that requires cache invalidation or not is to be decided on a case-by-case basis. It is a generic tool and it should stay as such. On 11 Dec 2017 19:00, "Martin Ninov" <notifications@github.com> wrote: > I was making changes to my model and had created a new entity, and was > using the schema tool to dump the raw SQL. > > I spotted a small mistake in my definition and after fixing it and dumping > again, the change wasn't reflected. > Eventually I discovered that when you have metadata caching, only the > first version of any new entity is recognised. Thereafter, no matter what > changes you make to your entity, the schema tool not reflect those, since > it has now cached the first version, and that's all it knows. > > Given the function of this tool, would it not be better to force it to > bypass caching altogether? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/doctrine/doctrine2/issues/6876>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAJakC6YMXWjjKuR895Hz5I6ujfKbkDjks5s_W2qgaJpZM4Q9zJF> > . >
Author
Owner

@martixy commented on GitHub (Dec 11, 2017):

For me, this seems an easy pit to fall into. While I wouldn't know the best solution to this, I believe it's a good idea to address this somehow - be it in code or documentation.

@martixy commented on GitHub (Dec 11, 2017): For me, this seems an easy pit to fall into. While I wouldn't know the best solution to this, I believe it's a good idea to address this somehow - be it in code or documentation.
Author
Owner

@Ocramius commented on GitHub (Dec 15, 2017):

Documentation patches are indeed welcome: just needed to clarify the design
decisions first 👍

On 11 Dec 2017 19:12, "Martin Ninov" notifications@github.com wrote:

For me, this seems an easy pit to fall into. While I wouldn't know the
best solution to this, I believe it's a good idea to address this somehow -
be it in code or documentation.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/6876#issuecomment-350809223,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakKrGpqifQNsWMLOKQW6BSeVZyIhhks5s_XChgaJpZM4Q9zJF
.

@Ocramius commented on GitHub (Dec 15, 2017): Documentation patches are indeed welcome: just needed to clarify the design decisions first 👍 On 11 Dec 2017 19:12, "Martin Ninov" <notifications@github.com> wrote: > For me, this seems an easy pit to fall into. While I wouldn't know the > best solution to this, I believe it's a good idea to address this somehow - > be it in code or documentation. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/doctrine/doctrine2/issues/6876#issuecomment-350809223>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAJakKrGpqifQNsWMLOKQW6BSeVZyIhhks5s_XChgaJpZM4Q9zJF> > . >
Author
Owner

@lcobucci commented on GitHub (Dec 17, 2017):

I'll close this issue as per @Ocramius comments.

@martixy please do send a PR improving the docs!

@lcobucci commented on GitHub (Dec 17, 2017): I'll close this issue as per @Ocramius comments. @martixy please do send a PR improving the docs!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5798