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.
Related
So the column in question was a lookup column, which i deleted in the unmanaged solution, and mistakenly created a new column with the same name. Dynamics by default will use the same auto-generated schema name based on the display name. So when I go to import the unmanaged solution in my dev environment into the production environment as managed, obviously it throws an error because of the mismatched of data types per column schema name.
Error returned by Azure Pipeline
So I did the sensible next thing, and went to delete this column in my dev environment. But oh no! There are object dependencies which prevent me from deleting it, okay I look at which objects depend on this column, it is a form, i remove the column from the form, go to delete and oh no again! There is still a dependency on the form I just deleted the column from.
So what do I do? I can't change the column schema name, I can't change the data type back to the data type that's currently in the managed solution. Is this when I open up a microsoft support ticket? Hopefully someone here has some insight. Thanks!
The attribute can be associated with a custom control. Try removing this custom control using the classic form designer. It should be visible on one of the field property tabs.
If the attribute cannot be found anywhere on the form using the classic or modern form designer, try this:
Create a solution with this form only. Export the solution as unmanaged. Extract the customization.xml from the zip. Edit the xml and remove all references to your attribute. Paste the customization.xml into the zip and import and publish the solution.
The only way to delete a managed component is to upgrade the solution. In your case, you can delete the field and dependency in solution and apply the upgrade to target environment. Please noticed that all data in this field would get deleted when you apply the upgrade. You may check this link for more detail
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.
I am able to successfully record changes to classes, and return what has been changed (not including many-to-many). However, I am unable to revert back any change using the built-in new transitionTo() method.
I get the following error on all classes:
Expected Auditable type App\XYZ, got XYZ instead
I have all of my morphable classes (which are all I am using for tracking audits) attached correctly within AppServiceProvider in a morphmap like so:
\Illuminate\Database\Eloquent\Relations\Relation::morphMap([
'Employee' => \App\Employee::class,
];
All classes work correctly with all other Laravel morphTo methods.
The auditable code looks like it is tripping the error in line 467 of the Auditable class:
if (!$this instanceof $audit->auditable_type) {}
It doesn't appear to be looking to the map for any of the morphed classes. Or, I could be totally missing something of course!
Any help on how to get this to work using the auditing method -- has anyone gotten this to work with standard morph classes? (It will of course revert the class manually by looping on the old fields and saving the object).
Using Laravel 5.5 and the latest version (5.0) of Laravel-Auditing.
Sent a note to the developer - this was in fact a bug. Vendor code was needed to include morphMapped objects.
Developer at Laravel Auditing responded within an hour and had a fix a few hours later. I can confirm this is now functioning as expected. Outstanding support.
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 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.