Doctrine 2 - ORM

Make it possible to force reloading of instanciated models

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0-ALPHA4
  • Fix Version/s: 2.0-BETA1
  • Component/s: ORM
  • Security Level: All
  • Labels:
    None

Description

When doing bulk UPDATE/DELETE it might be useful to tell the EntityManager to either mark a model instance as "dirty" or even force immediate reload.
So for example:
1) i update all user models -> mark all user model instances as outdated or force reloading all of them at once
2) i update a list of user models and i have the list of ids -> mark a specific list of user model instances as outdated or force reloading of them at once
3) i do various updates, after i am done i want to force reloading of all model instances that are outdated or if a specific type or of a specific list of ids per type

In the same vain I might want to do similar things after bulk deleting.

Furthermore in some cases I might do inserts which could mean that a collection is no longer "valid". imagine for example i insert a new record and i have a hydrated collection over all of the models in the DB.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Eberlei added a comment - - edited

Since UPDATE and DELETE only allow WHERE clauses i guess it could be possible to pass a query hint that additionally generates a SELECT query and executes it right after the update/delete statement, in combination with HINT_REFRESH.

Show
Benjamin Eberlei added a comment - - edited Since UPDATE and DELETE only allow WHERE clauses i guess it could be possible to pass a query hint that additionally generates a SELECT query and executes it right after the update/delete statement, in combination with HINT_REFRESH.
Hide
Permalink
Benjamin Eberlei added a comment -

@Lukas:

You can do it already, say you have:

UDPATE User u SET ... WHERE u.name = 'foo'

Just execute afterwards with $query->setHint(Query::HINT_REFRESH, true);

SELECT u FROM User u WHERE u.name = 'foo'
Show
Benjamin Eberlei added a comment - @Lukas: You can do it already, say you have: UDPATE User u SET ... WHERE u.name = 'foo' Just execute afterwards with $query->setHint(Query::HINT_REFRESH, true); SELECT u FROM User u WHERE u.name = 'foo'
Hide
Permalink
Lukas Kahwe added a comment -

awesome! but it would also be nice to just mark as dirty. after all you may not be sure that you will actually need the updated versions in the current request or not.

Show
Lukas Kahwe added a comment - awesome! but it would also be nice to just mark as dirty. after all you may not be sure that you will actually need the updated versions in the current request or not.
Hide
Permalink
Benjamin Eberlei added a comment -

The problem is, UPDATE an dDELETE are directly translated into SQL. How do you know from there which objects to mark as dirty?

Show
Benjamin Eberlei added a comment - The problem is, UPDATE an dDELETE are directly translated into SQL. How do you know from there which objects to mark as dirty?
Hide
Permalink
Lukas Kahwe added a comment -

that would need to be custom user logic. i would tell the entitymanager to either mark all instances of a model type or only those with a specific list of id's.

Show
Lukas Kahwe added a comment - that would need to be custom user logic. i would tell the entitymanager to either mark all instances of a model type or only those with a specific list of id's.
Hide
Permalink
Benjamin Eberlei added a comment -

Hm, rethinking is - there isnt really a marking "dirty" possibility for entities, since you would have them throw exceptions upon access or something like this.

The underlying issue of this ticket is "fixed" though. Marking closed.

Show
Benjamin Eberlei added a comment - Hm, rethinking is - there isnt really a marking "dirty" possibility for entities, since you would have them throw exceptions upon access or something like this. The underlying issue of this ticket is "fixed" though. Marking closed.

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Lukas Kahwe
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: