mirror of
https://github.com/doctrine/orm.git
synced 2026-04-29 17:33:15 +02:00
Warning: rename(...\var\cache\dev/doctrine/orm/Proxies\__CG__DemoProductBundleEntityProductBrand.php #5709
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xiranst on GitHub (Sep 21, 2017).
Originally assigned to: @Ocramius on GitHub.
when i query entity with doctrine, i got this error message.
the query code:
$category = $this->getDoctrine()->getRepository('DemoProductBundle:Category')->find($nameId); $i = 0; $products = $this->getDoctrine()->getRepository('DemoProductBundle:Product')->findBy(array('porductCategory' => $category)); foreach ($products as $product) { dump($i); $i++; }or
$category = $this->getDoctrine()->getRepository('DemoProductBundle:Category')->find($nameId); $i = 0; foreach ($category->getProducts() as $product) { dump($i); $i++; }Error Message:
when i used mysql_query replace doctrine, it worked.
$host = $this->getParameter('database_host'); $user= $this->getParameter('database_user'); $password = $this->getParameter('database_password'); $database = $this->getParameter('database_name'); $con = mysql_connect($host, $user, $password); if (!$con) { die('Could not connect: ' . mysql_error()); } mysql_select_db($database, $con); $sql = "SELECT * FROM demo_product WHERE category_id = $nameId"; // dump($sql); // exit(); $result = mysql_query($sql); $brandselect = "<option value='0'>please select...</option>"; while($row = mysql_fetch_object($result)) { $brandselect .= "<option value={$row->id}>{$row->title}</option>"; } mysql_close($con);There are my yml files:
product.yml
`Demo\Bundle\ProductBundle\Entity\Product:
type: entity
table: demo_product
id:
id:
type: integer
nullable: false
options:
unsigned: true
id: true
generator:
strategy: IDENTITY
fields:
title:
type: string
nullable: true
length: 45
options:
fixed: false
sn:
type: string
nullable: true
length: 45
options:
fixed: false
excerpt:
type: string
nullable: true
length: 45
options:
fixed: false
description:
type: blob
nullable: true
length: 65535
options:
fixed: false
thumbnail:
type: string
nullable: true
length: 100
options:
fixed: false
pdf:
type: string
nullable: true
length: 100
options:
fixed: false
stock:
type: integer
nullable: true
options:
unsigned: false
price:
type: string
nullable: true
length: 45
options:
fixed: false
status:
type: string
nullable: true
length: 45
options:
fixed: false
created:
type: datetime
nullable: true
modified:
type: datetime
nullable: true
`
productBrand.yml
Demo\Bundle\ProductBundle\Entity\Brand: type: entity table: demo_product_brand id: id: type: integer nullable: false options: unsigned: true id: true generator: strategy: IDENTITY fields: name: type: string nullable: true length: 45 options: fixed: false #简称 Abbreviation: type: string nullable: true length: 45 options: fixed: false sn: type: string nullable: true length: 45 options: fixed: false description: type: string nullable: true length: 45 options: fixed: false thumbnail: type: string nullable: true length: 45 options: fixed: false created: type: datetime nullable: true modified: type: datetime nullable: true lifecycleCallbacks: { }productCategory.yml
`Demo\Bundle\ProductBundle\Entity\ProductCategory:
type: entity
table: demo_product_category
`
what's wrong with my code? thanks.
@Jean85 commented on GitHub (Sep 22, 2017):
The issue is not with your code but with your dev environment. The error message points you toward the cache, which probably has the wrong permissions. You have to check your cache folder and fix the file permissions, but that may depend on what dev environment you have.
@xiranst commented on GitHub (Sep 22, 2017):
@Jean85 i tried to set cache permission. after clear cache, this error message is disappeared. but it will be displayed again in few times. the development environment is windows. i got this error when use ajax to load some data from database. if i pause 1-2 seconds for ajax loading, this error will not be displayed again.
@Xymanek commented on GitHub (Sep 30, 2017):
I faced the same problem. It isn't because of permissions, it's because doctrine tries to regenerate proxies on each of ajax requests (in dev) and tries to write the file at the same time (multiple requests). Therefore some of requests are denied file access by OS.
However I haven't this happen in quite a while now... Try updating both doctrine and symfony, maybe it was fixed at some point
@eluzgin commented on GitHub (Oct 1, 2017):
This issue as well as fix was documented here: https://github.com/doctrine/mongodb-odm/pull/1495
And here: https://github.com/doctrine/mongodb-odm/pull/1495
The HydratorFactory kept exploding on my local Docker about 50% of the time until I patched it locally by replacing single rename() operation with with copy() followed by unlink().
The authors of the library know about this issue and proposed fix but chose not to implement it.
@Ocramius commented on GitHub (Oct 1, 2017):
We need a reproducible test case to fix this.
On 1 Oct 2017 15:03, "Eugene Luzgin" notifications@github.com wrote:
@eluzgin commented on GitHub (Oct 1, 2017):
Unfortunately I can not share my docker image since project source code is not mine.
Here is the screenshot of error however:
Details:
@Ocramius commented on GitHub (Oct 1, 2017):
Well aware of the error, just need a way to prevent regressions (test
automation)
On 1 Oct 2017 15:23, "Eugene Luzgin" notifications@github.com wrote:
@alcaeus commented on GitHub (Oct 1, 2017):
Since you linked a pull request that suggested a change, allow me to also link the reason why I chose to not implement it: https://github.com/doctrine/mongodb-odm/pull/1495#issuecomment-251870697.
Money quote:
One option would be to add a
file_existscheck for sanity before callingrename, but if you can't manage your operating system to make a simplerename('/foo/bar/a', '/foo/bar/b')work, this isn't something we're going to work around, at least not in ODM. Just saying.@glennthehuman commented on GitHub (Aug 6, 2019):
What's the best solution now? (while the ORM isn't updated yet)
@eluzgin commented on GitHub (Aug 6, 2019):
The solution that we used for our project was to apply this change locally - it worked for us: https://github.com/doctrine/mongodb-odm/pull/1495/files
You mileage may vary.
@Ocramius commented on GitHub (Aug 6, 2019):
This has already been repeated twice in this thread.
@alcaeus commented on GitHub (Aug 6, 2019):
Yes, because an issue that stems from people misconfiguring their virtualised environments should be fixed with an untested patch that can have severe performance implications for everyone else. It can also cause fatal errors due to incomplete cache files being read while the copy operation is in progress.
Let me also ask you to tone down your language a bit: we’ve repeatedly explained why the solution proposed for ODM doesn’t work in most instances and that the issue is not with our code but the configuration of the system. This is the second time you’re insinuating that we’re not fixing that out of malice, and I won’t have it. Bring a fix with reproducible test cases that show you’re not introducing regressions for users that aren’t affected by this issue in the first place, or fix it for yourself without potentially introducing issues for millions of other users. Thank you for understanding.
@eluzgin commented on GitHub (Aug 6, 2019):
I apologize if I have insinuated anyones feelings. May comment was made with just a bit of sarcasm but no insinuating intentions. Regardless, this is an old problem.
I am no longer involved in the project when we experienced this problem.
I shared the approach we took to resolve the issue.
I do not believe this was due to any misconfiguration of our Docker environment.
If I was developer on this project I would code defensively and at least try to capture the error with rename (which happens on rare occasions) and try alternatives.
Just my 2c.
@ElMatella commented on GitHub (Nov 14, 2019):
A solution provided in https://stackoverflow.com/questions/12894822/access-denied-error-on-rename-call-when-uploading-files-in-symfony was appropriate for me:
@Ocramius commented on GitHub (Nov 14, 2019):
Check https://github.com/webimpress/safe-writer/pull/1 and help with improving that - this is a common problem of atomic file writes done via rename, and needs extensive testing, but "hacking our own" in here ain't happening unless very carefully tested.
Closing as "incomplete" here - please open a pull request if/when tests are part of a proposal.
@JackPotte commented on GitHub (Nov 14, 2019):
Same problem into vendor\doctrine\common\lib\Doctrine\Common\Proxy\ProxyGenerator.php:293. To test: