Skip to content

[TwigBundle] Reconfigure twig paths when they are updated #14773

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 0 commits into from
Closed

[TwigBundle] Reconfigure twig paths when they are updated #14773

wants to merge 0 commits into from

Conversation

chbruyand
Copy link
Contributor

Q A
Bug fix? yes
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #14771, #14768, #14262
License MIT

Directory's content and modification time are not considered any more for freshness check. Only it's creation or deletion are now checked.
This addresses performance issues (#14771, #14768), and also improves the cases were container is reconfigured as directory creation needed clearing the cache manually (#14262).

@chbruyand chbruyand changed the title Reconfigure twig paths when they are updated [TwigBundle] Reconfigure twig paths when they are updated May 28, 2015
@stof
Copy link
Member

stof commented May 29, 2015

@chbruyand just FYI, the email you used to commit is not associated to your github account

@stof
Copy link
Member

stof commented May 29, 2015

Adding a new feature in the Config component in 2.3 would be really weird IMO (and a pain in the ass to write requirements on the component when needing this feature)

*/
public function __construct($resource)
{
$this->resource = realpath($resource);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the usage of realpath means it is not usable inside phars

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK.

realpath() is also used in Config\Resource\FileResource, do you suggest removing it also there ?

@stof
Copy link
Member

stof commented May 29, 2015

IMO, you don't need both FileExistenceResource and FileAbsenceResource but a single FileExistenceResource. In the constructor, you should register the path (passed as argument) and whether the file exists. In isFresh, you would check whether file_exists returns the same value than the one registered in the resource. This would make the Resource much easier to use.

*
* @author Charles-Henri Bruyand <charleshenri.bruyand@gmail.com>
*/
class FileAbsenceResource implements ResourceInterface, \Serializable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is is necessary to implement \Serializable?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mpdude it makes the meta file much smaller when serializing resources

@mpdude
Copy link
Contributor

mpdude commented May 29, 2015

Agree to @stof's comment above. You might even just pass in the path and the resource itself checks whether or not it exists (and will repeat the same check in the future when freshness is checked).

@stof
Copy link
Member

stof commented May 29, 2015

IMO, adding new resource types should be done in the 2.8 only, to avoid breaking semver.

@fabpot it looks like there is an issue with fabbot.io. It says "Not Found" as status.

@chbruyand
Copy link
Contributor Author

I removed usage of realpath and merged FileAbsenceResource and FileExistenceResource.

About your concerns for the Config component, what do you suggest ? Adding FileExistenceResource to the TwigBundle would be weird too.

private $exists;

/**
* Constructor.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd just remove this comment. It doesn't bring any value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I do the same in other Resources ? (same question for missing docblock)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it's not part of your PR. I just don't want to introduce new comments like this.

@chbruyand chbruyand closed this May 29, 2015
@chbruyand
Copy link
Contributor Author

Made a mistake, sorry for the noise. #14778

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants