I have 53 tables and a lot of them reference eachother with relationships. When i run:
php app/console doctrine:schema:create
I get the error maximum nesting level of 100 reached. Through research i found this is actually a security measure from xdebug to stop infinite loops. When i remove this limitation and run the command again the php cli stops working and im forced to close it.
Is there anyway to generate the schema in steps like build the database structure then go back and add the mappings and the indexes so that it doesnt fail?
Or is it possible that I am doing something else wrong?
MySQL does work and i can create schemas that have less tables / relationships using this same method.
UPDATE: doctrine:schema:create --dump-sql hangs as well. Both max nesting level and max execution time are set to unlimited. Still PHP CLI stops working:
Problem signature:
Problem Event Name: APPCRASH
Application Name: php.exe
Application Version: 5.3.26.0
Application Timestamp: 51af706d
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.17725
Fault Module Timestamp: 4ec49b8f
Exception Code: c00000fd
Exception Offset: 0002e8fb
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 8983
Additional Information 2: 898375922a25a99ebc5721487ed92891
Additional Information 3: f337
Additional Information 4: f3378ae3d6023e7f336317eca89ba0b7
You have to increase the value of xdebug.max_nesting_level ( which defaults to 100 ) in your php.ini to circumvent the maximum nesting level of 100 reached error.
You'll most likely run into this issue multiple times for example during cache warmup - not only when trying to create the database schema. Therefore increase the value for all your symfony development - same goes for magento and zf ...
Check the max_execution_time setting aswell and maybe inspect using a profiler (xdebug/xhprof) if the command seems to hang. It might take some time to create the schema, bring some patience :)
There are no options for the doctrine:schema:create command to "split" the operation.
Try if doctrine:schema:create --dump-sql hangs aswell.
A really dirty workaround:
You could define new kernel environments (i.e. step1, step2), create different mappings (getting more and more detailed) or manually configure only a few of them in the first "steps"/environments, register/override them in config_stepx.yml and use something like
doctrine:schema:create --env=step1
doctrine:schema:update --env=step2
...
... but that would really be a mess.
from my experience the command should work even for large datasets. i have created schemas for applications with >100 tables without any problems.
The answer is my entities had a self referencing one to one relationship on the same key that was being used as the primary key. Thus creating an infinite loop during creation.
Not really sure why it was there in the first place some of these were generated by the doctrine database reverse engineering command.
Related
I am working with Symfony and Doctrine for the first time. I am curious: Is there a simple way to reverse a set of changes generated via a single running of the doctrine:generate:entity command?
I don't have any specific reason (yet) for asking this. I just imagine that it could potentially be helpful for me at some time in the near future, especially since my current version control only covers changes to the filesystem, omitting modifications to my sandbox's database contents -- which is relevant here.
In other words, some real equivalent for my imagined command doctrine:generate:rollback would be ideal. I'm assuming there's probably a way to do this type of thing.
Edit: TIL that the doctrine:generate:entity doesn't actually do anything to the database on its own. In many workflows, the doctrine:schema:update command does that after entities have been generated.
No, there is no Symfony or Doctrine command to do a rollback, but what doctrine:generate:entity really does is generating new php file with entity definition. So an actual rollback for doctrine:generate:entity is:
rm /path/to/your/entity.php
The answer is: No, there is no 'rollback' command, which removing all changes.
Do not forget that all changes in file system you can rollback via GIT (or other VCS).
I have two Silverstripe websites running in the same WAMP 2.5 environment, sharing the same _ss_environment.php file (which sets database permissions etc.)
Both are:
Silverstripe 3.2.0RC1
Installed/ updated via Composer
PHPUnit 3.7.28
When I go to localhost.example/dev/tests I get completely different behaviour:
Site #1 runs the tests without any issues and returns the expected output.
Site #2 won't run any test and comes back with this sort of error:
Couldn't run query:
SELECT DISTINCT "Group"."ClassName", "Group"."LastEdited",
"Group"."Created", "Group"."Title", "Group"."Description",
"Group"."Code", "Group"."Locked", "Group"."Sort",
"Group"."HtmlEditorConfig", "Group"."ParentID", "Group"."ID", CASE
WHEN "Group"."ClassName" IS NOT NULL THEN "Group"."ClassName" ELSE
'Group' END AS "RecordClassName"
FROM "Group"
WHERE ("Group"."ID" = ?)
LIMIT 1
Table 'ss_tmpdb6760406.group' doesn't exist
What the heck is going on?
The Site #2 does have more modules installed but I can't see how that'd affect MySQL permissions/behavior.
The only difference that makes sense to me is Site #1 was a clean composer install on 3.2.0RC1 when Site #2 has been upgraded from an earlier version of Silverstripe (via composer).
Does anyone have any idea of what is going on and how I can get Site #2 to test properly?
After removing two unmaintained modules from Site #2 the unit testing is working fine.
I'm guessing there were bugs in the modules but I don't understand how they would have caused database errors in unrelated tests.
I had a similar issue. My solution was to completely purge the contents of silverstripe-cache directory (or whichever directory your particular TEMP_FOLDER constant points to) and run sake dev/build.
Not exactly sure why, but I believe there was an error at some point in building a class manifest and that was cached and was somehow preventing the proper rebuilding of the database schema, resulting in most tables being created except for just a few which were then being inserted into by a fixture file (which then triggered this error). Explains why it worked in the CI server, but not on my local machine. Unit tests are supposed to be totally isolated... 🙄
I'd suggest that you try changing the case-sensitivity setting in MySQL. I've seen similar things before, seemingly randomly occurring, and usually on the main database rather than under test.
I don't have a ton of experience with WAMP, but it sounds like you need to find my.ini (saving MySQL settings) and adjust the following setting:
lower_case_table_names=2
Have a look at the docs: http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html
And this other question: How to force case sensitive table names?
I can't guarantee that will solve your problem but it's the first place I would check, assuming SQLite is not an option for you as indicated in the comments above.
I am running a set of migrations that denormalize one of my tables. I am running some code in one of the migrations that sets the ids in a new table based on the content of the current table.
For some reason, the id is not getting written correctly. To debug this, I would like to echo some of the variables out to the command line when I run the migration (in development). However, I have so far been unable to get those commands to work.
Yes, you can use all the usual ways (echo, var_dump, print_r). They will output normally to the command line in migrations.
If you suspect (as I did) that something about Laravel's migration system is silencing them, you are barking up the wrong tree.
I have several foreach loops to show all players in a game. There are 10 players in the table, with an id column of type int, auto-incremented. The code looks like this:
foreach(Player::all() as $player) {
echo $player->id;
}
On my dev Mac, MySQL 5.1.70, I get: 1 2 3...
On my prod server, MySQL 5.5.31, I get: 1 10 2 3 4 ....
This is consistent in every other place in my code. Now, I get that this is an alphanumeric sort. The question is: why? What can I turn on on the server to get it to match my dev machine, without performing broad code changes?
I'm using PHP 5.4, Apache 2.4, Laravel 4.0.5 with Eloquent
Update:
I found another symptom to this, which might actually be the root cause of the problem: upon analyzing client-side AJAX calls to the server, I found that values return as ints from the dev server, but as strings from the prod server - causing tons of misbehaviors. This explains why I get an ASCII sort. But agai, the question is: what do I need to "fix" on the prod server for this to work?
For posterity's sake, here's the full answer.
First - thanks to #Wrikken - he nailed it in the comments. If he enters it as an answer, I'll mark it correct.
The differences I found between servers:
With MySQL 5.5, the default database engine is InnoDB, as opposed to MyISAM on my machine. That, somehow, effects default sorting order. So one solution was to add a line to the Eloquent schema creation, to ensure that the table gets created on the MyISAM engine:
Schema::create('blah', function($t) {
$t->engine = "MyISAM";
$t->increments('id');
//more fields ...
});
The reson all AJAX results returned as strings on the prod server, as opposed to int, float, boolean etc. on my dev machine, was because the MySQL Native Driver was not installed on the prod machine. After some trial and error, what needed to be done to solve this was to install mysqlnd (sudo yum install php54-mysqlnd - pay attention to the 54!), and restart Apache.
Finnaly, there remains the fact I was relying on server behavior to provide predictive program behavior - a big mistake. So I changed all the ::all() calls in my code to ::orderby('id')->get(), and now I get what I need, regardless of server, engine, database, etc.
I used PHP to create MongoDB database. My problem is that every time I create a database, the database's "size on disk" is some 200MB. I want to reduce it down to 25-50MB every time.
I have tried to use "command" and look in the .conf file for MongoDB without luck.
I run CentOS 6.2 if it helps.
If you run the command mongod --help you will see various options you can add when you start-up MongoDB. Two you may want to research are:
--noprealloc disable data file preallocation - will often hurt
performance
--smallfiles use a smaller default file size