Some time ago I created migration with date format like this 2019_2_090000. It worked ok, but today this migration dont work until name changed to 2019_02_090000. Is where any way to make migration work with old name? If name changed laravel recognizes migration as new which results in errors in old databases where this migration already executed.
You can name your migration files however you want. When laravel runs them however, it depends on the filename to know which one comes first (they are run in ascending order). Just make sure to give them the filename you want before actually running them.
The reason is simple: when you run a migration, the filename gets saved to your database so you have to keep it consistent.
As long as you keep that in mind, you can use whatever naming convention you want.
Related
I am translating my application through *.po-files, but the command
mix gettext.extract --merge
generates options only for hardcoded strings.
I have read in documentation that I can't edit *.po-files manually because they are overwritten every time.
How can I translate errors that come from changeset validations and so on?
dgettextfor errors is called in web/views/error_helpers.ex
I'm not sure if these get extracted and merged into errors.po, but that's where you'd likely put them manually if they do not.
I'm having some problems with doctrine-migration.
Changed the code in my schema.yml to add a new column:
filesAttached: {type: array}
After that, I ran doctrine:generate-migrations-diff, and although the message says "Generated migration classes successfully from difference" and a temporary doctrine_schema.yml is created, there is no migration class under my /lib/migration/doctrine folder.
Even if I try to run doctrine:migrate, it tells me that my migration is at the latest version.
I've used migrations before (2 days ago, I think) and everything worked just fine.
Any idea on what I'm doing wrong?
Unfortunately the auto generated migrations sometimes behave in such way (I never felt like diving into it and finding the reason).
What I would suggest if you have some other migrations classes is to write your own classes based on what you have. Just remember to change the class name to the next version number and give the file a name which is "greater" than the last file you have.
E.g. if you have class version_3 in file version3_334455.php just name it version_4 and put in version4_334456.php.
As to the syntax of the migration you should use this shouldn't be very difficult to figure it out based on the files you already have generated.
I'm struggling with an issue for which I can't find an explanation. I have two development environments that I use for my projects. I created a simple module for Magento and I tested it on one environment. After overcoming all Magento's complications, the module works as expected. This is on XAMPP.
I then copied the module to the development Linux environment, on a hosted server, and it crashes miserably. I did some debugging, and I found out that a call to Mage::getModel() returns bool(false) instead of the instance of the Model I requested.
I double checked all files and directories, and they match. Database is not involved (not from my side, at least, I don't need tables) and both environments have only me as a User, with Admin permissions.
Any suggestion on where should I start looking is welcome, thanks.
Added on 2012/07/09
Model contains a class named Diego_ClientCustomModule_Model_ExternalUserData, which is invoked with $model = Mage::getModel('clientcustommodule/externaluserdata');. Model file resides in Diego_ClientCustomModule\code\local\Diego\ClientCustomModule\Model\. The curious thing is:
If model file is named Externaluserdata.php, it works.
If model file is named ExternalUserData.php (i.e. it matches the class name), it doesn't work.
I'm aware of case sensitivity stuff etc, but, if the alias is all lower-case, how comes it can load a file having the first letter capitalized?
Configuration file
0.1.0
Diego_ClientCustomModule_Helper
Diego_ClientCustomModule_Model
Diego_ClientCustomModule_Block
standard
Diego_ClientCustomModule
ClientCustomModule
Snarking about the framework for which you are asking for help may not be the best strategy for receiving help.
Your issue is likely one of cache (remove var/cache folder to check) or one of improper casing. Note that the first letter of each directory and filename for files loaded by the autoloader (blocks, models, and helpers).
It seems I have found the root cause of the issue, although I can't figure out what kind of logic has been implemented to make it happen.
Model's file name was UserCustomModule.php, which reflected the class name UserCustomModule. That made sense, and worked wonderfully in XAMPP. Once I installed the same module on a Linux box, Magento silently ignored the file and, as previously stated, there's been no way to track down Magento's actions.
Following benmark suggestion, I went through all the files again to check the casing, and everything seemed to match. I then made something, in my opinion, completely stupid, and I renamed the Model file to Usercustommodule.php, leaving the class name untouched (after all, PHP should behave the same on both platforms, unlike the file system). Magically, the module now works! The file name looks cr*p, but it works.
This solved the problem, yet it raises more questions:
For what reason Magento has troubles loading a file with a CamelCase name? If it's Autoloading, it should simply find a file and load it. After all, it loads the Controller, the Block and everything else, and they are all in CamelCase.
Is it written anywhere that one or more files must have only the first letter capitalized? I got enough surprises already, I'd like to avoid new ones, if possible.
Thanks again for the help.
I'm a bit lost how I should get the entity framework to work with automatic migration. I want:
The database to be created automatically when it doesnt exist
The database to be updated automatically when the model changed
For the latter I'm using DbMigrator. It is rather slow so I don't want to run it every request, and also I have multiple databases in the same application so it cant go in Application_Start which is why I put it in Session_Start like this:
if (Session["started"] == null)
{
// this takes care of any database updates that might be necessary.
MigrationConfiguration configuration = new MigrationConfiguration();
DbMigrator migrator = new DbMigrator(configuration);
List<string> pm = migrator.GetPendingMigrations().ToList();
if (pm.Count > 0)
{
migrator.Update();
}
}
else
{
Session["started"] = "started";
}
Not sure if this is the right way to do it but it seems to work, however it doesnt actually generate the database when it doesnt exist. It gives me a "Cannot open database "db" requested by the login"
I had this working before with the following:
Database.SetInitializer<DbContext>(new InitializerIfModelChange());
This drops the database and generates seed data which is fine for when the database doesnt exist but it also is triggers when the database is changed (in which case I would like DbMigrator to handle it) This was in Application_Start before but I'm not sure what to do with it. I'm afraid that it will conflict with the DbMigrator. How would I set this all up in order to achieve the two things described earlier?
I manually run the Update-Database in the package manager whenever the database needs to be changed. Initially I used the Database.SetInitializer like you did to create the database but have it commented out now.
Checkout Entity Framework 4.3 Automatic Migrations Walkthrough for more advanced help.
This should work for what you want, then if you need to create a new database just add Database.SetInitializer<NewDBContext>(new NewDBInitializer()); like you had, build and run. Then comment it out so it doesn't run in the future on a model change and instead use the Update-Database command in the package manager.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.