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.
Related
I recently downloaded a Single Page Web Application (Angular) from https://aspnetboilerplate.com/Templates using 3.x target version.
I just simply added a few entities and then started to follow the steps on this page https://aspnetboilerplate.com/Pages/Documents/Application-Services
Things do work well for me to Get, List, Update, and Delete entities when my app service class is just inheriting AsyncCrudAppService<Entities.PhoneBook, PhoneBookDto, long, GetAllPhoneBooksInput>, however when it is inheriting AsyncCrudAppService<Entities.PhoneBook, PhoneBookDto, long, GetAllPhoneBooksInput, CreatePhoneBookInput, and UpdatePhoneBookInput> the swagger definition will no longer load.
GitHub Repo: https://github.com/woodman231/MyPhoneBooks
(which currently does not work and will not load Swagger page).
I can get the swagger page to load by removing CreatePhoneBookInput and UpdatePhoneBookInput from
https://github.com/woodman231/MyPhoneBooks/blob/main/aspnet-core/src/MyPhoneBooks.Application/SimpleCrudAppServices/ISimplePhoneBookCrudAppService.cs#L9
and
https://github.com/woodman231/MyPhoneBooks/blob/main/aspnet-core/src/MyPhoneBooks.Application/SimpleCrudAppServices/SimplePhoneBookCrudAppService.cs#L14
However, again I am still unable to create entities using this default implementation. Any ideas?
I have cloned your repo and run it and I figured out the error, first as I tell you in comments I verified the text log, and it said the next:
System.InvalidOperationException: Can't use schemaId "$CreatePhoneBookInput" for type "$MyPhoneBooks.SimpleCrudAppServices.Dtos.CreatePhoneBookInput". The same schemaId is already used for type "$MyPhoneBooks.PhoneBooks.Dtos.CreatePhoneBookInput"
What happenig is that you have these two classes UpdatePhoneBookInput, CreatePhoneBookInput repeated in SanokeCrudAppServices\Dtos and PhoneBooks\Dtos
You have the classes in both folders with same exact name, and thats the problem, if you change the name in whatever place the swagger definition will load without errors, I have do it like this and everything works fine!
Change the name in one of the places, and all will be working fine
Personally I don't like to use a different Dto for Create and Update for me is easier to user just one Dto for all.
Ok I figured it out. I had also made a DIY AppService and some of the DTO Class Names associated with the DIY App Service clashed with the DTO Class Names associated with the Automated Service. It was acceptable in .NET since they were in different name spaces but once the swagger definition was configured I assume that there was multiple instances of the same DTO Defition. I checked the AbpLogs table but they didn't give me much details as to the specifics of the internal server error while loading the definition. It sure would have been useful to know that.
I've edited some existing visual queries of Blog 4.0 application and when I was debugging it - it worked perfectly. But then on page it stopped working. Any attempt to use key with Data like Data["Posts"] raises System.Collections.Generic.KeyNotFoundException. App.Query["Blog Posts List"]["Posts"] returns something, but any attempt to access its fields raises another exception (don't remember the name, but it said that there's no such member inside that object).
I didn't rename queries, I didn't change application settings. I just edited logic of 2 queries. I renamed 1 wiring endpoint name across 3 queries in whole chain.
How do I debug it? How can I see what does cshtml receive from database so I don't guess and put my crystal ball away?
In general, App.Query["Name of Query"] will get you the streams of data. You usually need to convert it using AsDynamic() or AsList() to something you can work with.
This should help some; What is Data?
If you're just running into problems with field names, you probably forgot the AsList or AsDynamic, just like #accuraty-jeremy mentioned.
For real debugging, go to insights, you'll see what happens - but in your case it probably won't help, because your working with an object that's not dynamic (so doesn't support .FirstName) until you AsList/AsDynamic it.
My bad: I confused two different files - _List.cshtml and _List Paging.cshtml. So I was searching for an error in the code of wrong file.
I currently have a Gatsby project based on the Gatsby-Ghost-Starter project. The Ghost schema is no longer being generated in Gatsby for some reason, and I can't seem to figure out why. As a result, I get the following error:
There was an error in your GraphQL query:
Cannot query field "icon" on type "GhostSettings".
If you don't expect "icon" to exist on the type "GhostSettings" it is
most likely a typo. However, if you expect "icon" to exist there are a
couple of solutions to common problems:
If you added a new data source and/or changed something inside gatsby-node.js/gatsby-config.js, please try a restart of your
development server
The field might be accessible in another subfield, please try your query in GraphiQL and use the GraphiQL explorer to see which fields
you can query and what shape they have
You want to optionally use your field "icon" and right now it is not used anywhere. Therefore Gatsby can't infer the type and add it to the
GraphQL schema. A quick fix is to add a least one entry with that
field ("dummy content")
It is recommended to explicitly type your GraphQL schema if you want
to use optional fields. This way you don't have to add the mentioned
"dummy content". Visit our docs to learn how you can define the schema
for "GhostSettings":
https://www.gatsbyjs.org/docs/schema-customization/#creating-type-definitions
This error message is basically repeated for every page and query field that uses anything related to the Ghost schema. I pulled up the GraphiQL explorer to see if I could access the fields there, and it indicated there is no schema available (as seen in the screenshot here). I tried rolling back to previous commits, deleting .cache and node_modules, updating all packages, and re-cloning the repo to no avail.
My latest commit was able to compile with no problem in the production environment, so I think it's some sort of misconfiguration on my machine...The environment variables are all identical, and I tried using the production Ghost server as my "ghost-source" on my local machine (since I know it works if the production build compiled successfully), but nothing changed. I've been stuck on this for days and have no idea how to even debug what's happening right now. Any advice/insights would be greatly appreciated.
I don't know why but MagicalRecord delete my store every time I reboot the application, I saw in the documentation :
When using the default sqlite data store with the DEBUG flag set, if you change your model without creating a new model version, Magical Record will delete the old store and create a new one automatically. No more uninstall/reinstall every time you make a change! (see magicalRecord github page
Removed the DEBUG flag,Tried to create a new model version, MR is still deleting my store...
Help me please :-)
This may be a bug. Please add an issue to the github repo. Or, if you need to get going faster, you can peek into the code, and comment out the line that checks to see if your model is compatible with your persistent store.
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.