purpose:
generate sql like:
select * from photo p
left join artist a on p.artist_id = a.artist_id
where a.genre = 'something' and p.genre = 'something'
code:
if(!CriteriaUtil::hasJoin($criteria, ArtistPeer::TABLE_NAME)){
$criteria->addJoin(PhotoPeer::ARTIST_ID, ArtistPeer::ARTIST_ID, Criteria::LEFT_JOIN);
}
$criteria->add(ArtistPeer::GENRE, $genre);
$criteria->add(PhotoPeer::GENRE, $genre);2. join two tables, add AND OR between conditions
purpose:
generate sql like:
select * from photo p
left join artist a on p.artist_id = a.artist_id
where (a.genre = 'some' or p.genre='something')
and a.name = 'something'code:
if(!CriteriaUtil::hasJoin($criteria, ArtistPeer::TABLE_NAME)){ $criteria->addJoin(PhotoPeer::ARTIST_ID, ArtistPeer::ARTIST_ID, Criteria::LEFT_JOIN); } $criteria->add(ArtistPeer::GENRE, $genre); $c = $criteria->getCriterion(ArtistPeer::GENRE); if($c != null){ $c->addOr($criteria->getNewCriterion(PhotoPeer::GENRE, $genre)); } $criteria->add(ArtistPeer::NAME, $name);
Note:
It's a good habit to check if we have joined the table already. to check this, you can use the following util class, it get all the joined tables, and check if the table exists in them.
class CriteriaUtil{ public static function hasJoin($c, $table_name){ $joins = $c->getJoins(); if($joins != null){ foreach($joins as $join){ if($join->getRightTableName() == $table_name){ return true; } if($join->getLeftTableName() == $table_name){ return true; } } } return false; } }
]]>
Clearing Selective Parts of the Cache
During application development, you have to clear the cache in various situations:
- When you create a new class: Adding a class to an autoloading directory (one of the project's
lib/folders) is not enough to have symfony find it automatically. You must clear the autoloading configuration cache so that symfony browses again all the directories of theautoload.ymlfile and references the location of autoloadable classes--including the new ones. - When you change the configuration in production: The configuration is parsed only during the first request in production. Further requests use the cached version instead. So a change in the configuration in the production environment (or any environment where
SF_DEBUGis turned off) doesn't take effect until you clear the cached version of the file. - When you modify a template in an environment where the template cache is enabled: The valid cached templates are always used instead of existing templates in production, so a template change is ignored until the template cache is cleared or outdated.
- When you update an application with the
synccommand: This case usually covers the three previous modifications.
The problem with clearing the whole cache is that the next request will take quite long to process, because the configuration cache needs to be regenerated. Besides, the templates that were not modified will be cleared from the cache as well, losing the benefit of previous requests.
That means it's a good idea to clear only the cache files that really need to be regenerated. Use the options of the clear-cache task to define a subset of cache files to clear, as demonstrated in Listing 18-14.
Listing 18-14 - Clearing Only Selective Parts of the Cache
// Clear only the cache of the myapp application
> symfony clear-cache myapp
// Clear only the HTML cache of the myapp application
> symfony clear-cache myapp template
// Clear only the configuration cache of the myapp application
> symfony clear-cache myapp config
You can also remove files by hand in the cache/ directory, or clear template cache files selectively from the action with the $cacheManager->remove() method, as described inChapter 12
Note:
1. We can use $cacheManager->remove() to clear cache after we deployed a new version product.
2. write code to generate models from database, and then call $cacheManager->remove() to clear cache.
]]>