Development

#3467 (doctrine:data-load: The "default" context does not exist.)

You must first sign up to be able to contribute.

Ticket #3467 (reopened defect)

Opened 5 years ago

Last modified 1 year ago

doctrine:data-load: The "default" context does not exist.

Reported by: carsten Assigned to: chtito
Priority: major Milestone:
Component: sfDoctrinePlugin Version: 1.4.1
Keywords: Cc:
Qualification: Unreviewed

Description

doctrine:data-load and doctrine:data-dump cause the error: 

The "default" context does not exist.

This is caused by line 115 in sfDoctrinePlugin/lib/sfDoctrineQueryLogger.class.php: 

sfContext::getInstance()->getLogger()->log($message);

The tasks work if that line is commented out.

sfDoctrinePlugin svn revision: 8759

Change History

05/13/08 04:20:14 changed by Jonathan.Wage

  • status changed from new to closed.
  • resolution set to fixed.

This is fixed in sfDoctrinePlugin/trunk, I will be removing the branch as it is not necessary and not being maintained. Trunk is where bug fixes and active development are going on for symfony 1.1

11/23/08 12:02:57 changed by Mickael.Kurmann

  • status changed from closed to reopened.
  • version changed from 1.1.0 BETA4 to 1.1.5.
  • resolution deleted.

I'm having the same issue with doctrine's 1.1 branch, is this branch up to date ? Or do I need to use trunk with sf1.1 ?

Thank you

11/27/08 10:30:11 changed by Jonathan.Wage

  • status changed from reopened to closed.
  • resolution set to fixed.

This is fixed in symfony 1.2

11/25/09 15:50:59 changed by plus

  • status changed from closed to reopened.
  • version changed from 1.1.5 to 1.2.9.
  • resolution deleted.

I have the same problem with symfony version 1.2.9

Exception trace: 

  at /home/plus/projects/lib/symfony/plugins/sfDoctrinePlugin/lib/cli/sfDoctrineCli.class.php:69
 sfDoctrineCli->notifyException at /home/plus/projects/lib/symfony/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Cli.php:93
 Doctrine_Cli->run at /home/plus/projects/lib/symfony/plugins/sfDoctrinePlugin/lib/task/sfDoctrineBaseTask.class.php:112
 sfDoctrineBaseTask->callDoctrineCli at /home/plus/projects/lib/symfony/plugins/sfDoctrinePlugin/lib/task/sfDoctrineDataDumpTask.class.php:87
 sfDoctrineDumpDataTask->execute at /home/plus/projects/lib/symfony/task/sfBaseTask.class.php:63
 sfBaseTask->doRun at /home/plus/projects/lib/symfony/task/sfTask.class.php:77
 sfTask->runFromCLI at /home/plus/projects/lib/symfony/command/sfSymfonyCommandApplication.class.php:76
 sfSymfonyCommandApplication->run at /home/plus/projects/lib/symfony/command/cli.php:20
 include at /home/plus/projects/wbc/symfony:15

12/17/09 11:55:41 changed by krojew

I've encountered this problem with sf 1.4.2-DEV

06/10/10 22:20:51 changed by brent960

I am encountering this issue in symfony v1.4.5 with Doctrine.

When I switch the version used back to v1.4.4 in ProjectConfiguration?.class.php, there is no problem.

But in v1.4.5, when I go to load fixtures, I see this error: The "default" context does not exist.

07/08/10 10:12:12 changed by fedulov.ivan

  • version changed from 1.2.9 to 1.4.1.

The same problem when runing task doctrine:data-load in simfony versions 1.4.1 and 1.4.6

08/26/10 23:41:03 changed by pulse00

i'm getting the same error when running doctrine:build-sql (symfony 1.4.7)

11/08/10 19:30:58 changed by victoruiz

I'm getting exactly the same error when running task doctrine:data-load in symfony versions 1.4.2

11/08/10 19:37:30 changed by victoruiz

I've solved my problem following other symfony user's case: "Retracing my steps, the problem was in the save() overriding function I am using". In my case it was a postSave() overriding function.

Link: http://oldforum.symfony-project.org/index.php/m/94091/

So wasn't a bug in my case, just my fault.

02/28/12 20:34:10 changed by fishbone

For some tasks (e.g. doctrine:data-dump) you'll get this error if you override the getter for an existing field (e.g. getTitle()) and if this method calls sfContext::getInstance() (In my case I called the logger)

In this case it's of course not a bug in Symfony.