We have a large application with hundreds of classes/enums, and we want to use MongoDB to store some of these.
The situation is that there is a current system whereby we binary serialize the .NET object into a field in a SQL database, then deserialize on demand. What we want is put the object into Mongo in a way that will allow us to query the object's properties directly (ie. without having to load the object into memory, deserialize, etc.). This is so we can start to get some analytics from the historic data without having to drastically change the code base.
My question is, is this something that easily possible? are there in built serializers in the C# driver to do this?
I'm also open to answers that propose a better way to do this if what I'm trying to do is inherently wrong.
Update: to be clear, what I'm trying to do is take an object that has been loaded using NHibernate, and insert it into Mongo as a Queryable object. Ultimately, I'll want to load it back into memory at some point too.
MongoDB is basically a store of JSON documents, so if you can serialize your objects in a JSON way, you should be ok to store it in MongoDB, and I assume there are lots of JSON serializers for .NET, so should be easy to find one.
Once everything is stored as JSON in MongoDB you will be able to query it without any more tools that the ones to query the database directly.
Regards,
You can use Simple.Data.MongoDB a lightweight, dynamic data access .NET component for MongoDB
Related
When the server stores data in a MongoDB database and is accessed through GraphQL, it would be cool if local/cached versions of the same data could be stored similarly - in some sort of local NoSQL data store.
However, from my research it looks like there aren't that many data persistence options available in Flutter and the best one available is SQFLite. If I use SQFLite, though, I have to wrangle different formats of the same data - the nested-object NoSQL/GraphQL format and the "separate objects joined through relations" format of SQL.
Has anyone dealt with this before? Even if you're not using MongoDB/GraphQL in your remote backend, your API likely still returns nested objects which can't be stored as-is in your local SQL DB and can't be used interchangeably with their locally persisted versions.
So how would you deal with this issue and achieve clean syncing of local and remote data without it turning into a mess?
I'm trying to store configuration in MongoDB. I want the document schema to be dynamic so as to store different type of configuration in the collection. The configuration may consist of more than just simple string key-value pairs. While using spring-data-mongodb, I see that I need to define a class which is usually mapped to a mongodb. So, when I need to add more configuration to the collection, I need to make changes to the class. I don't really want to do this as I want to be able to modify configuration without code changes (and ideally without restarting long-running applications). Also, what I'm eventually storing is configuration which should be consumed by different services, so I can't really have a well-defined schema. Instead, I would want the services to pull configuration from the store (i.e. provide key, get value). This makes me doubt where spring-data-mongodb is the right choice for such a use-case. Is there any obvious solution or alternative to my use-case?
Thanks in advance.
The obvious solution is use just the Java driver for MongoDB. The Java driver has an implementation of BSON's spec and you can work with BSON/JSON objects instead classes.
One thing I have in mind is, that datasets in Core Data (or lets say: managed objects) have no ID like known from other databases such as MySQL. Also, they're not in a specific guaranteed order.
What else makes Core Data much more "special" compared to working with a relational database like MySQL? Besides the whole object graph persisting and ORM stuff?
This is a good article explaining the main differences. The biggy for me is
'Core Data cannot operate on data
without loading the data into memory'
This alone makes core-data and MySQL suited to totally different tasks.
The big difference I would say is that Core Data is built on an ORM, an Object Relational Mapping, while MySQL is just a relational database. You could actually host CoreData on MySQL if Apple wanted to let you. Instead they use a different embedded SQLight solution or an XML representation depending on what you want for your backing store.
I have started working on an iPhone application that where I need to synchronize data with an external MySQL database. The current database scheme uses GUID/UUID fields as primary keys to maintain relationships between tables. I already have this working between a database app and the MySQL database, so this isn't a question regarding synchronization per say.
I've started going down the path of using Core Data, but I'm realizing that it maintains relationships between entities using it's own schema within the SQLite database.
Am I going down the wrong path using Core Data? If not how does one synchronize data between a Core Data store and an external database and still maintain the data relationships?
All you need to do is write the logic to translate entities from one db schema to another. You can fetch objects from the server and convert them to core data objects, and fetch object from core data and convert them to mysql entities when saving to the server. Nothing too difficult involved really
I agree with Griffo; simply translate the rows or entities you retrieve from the mysql database into managed objects (and visa versa).
If I understand what you are looking to correctly, I would definitely recommend using Core data. Translating the data between MySQL and Core Data isn't that hard, and if you use an NSFetchedResultsController to display your data in a UITableView, you practically don't have to write any code.
and you can always preserve the original GUIDs as, for example, optional externalIDs for the imported entities. This way you will be able troubleshoot your data imports easier and correlated the data between the to types of the data stores.
Does anyone have any advice on using a datastore with mapkit to provide a database of locations (Restaurants) that are query-able by location?
I would like to use Core data but importing the information into it seems like a project in itself. If anyone has good advice on converting an existing sqlite/cvs file to a coredata sqlite file that would be appreciated.
Is old-fashioned sqlite better than using core data for the task, or is it a case that I should create a web service for the job?
I would like to be able to query the locations based on the map zoom also.
Thanks if you have any advice on the matter.
If you write your object model correctly, you can just point it at an existing sqLite database and it will read it as if core data generated it in the first place.
For example, suppose you have an existing sqlite db of people with columns like firstName, lastName, phone# etc. You just create a core data model with a entity with attributes of firstName, lastName, phone# etc. Spell them the same and make sure they have the right type and then point the NSPersistentStoreCoordinator at the existing database. It will read it in fine.
Core data is always the way to go for any larger data management task. It makes everything so much easier once you learn it.
Edit01:
Never mind the above. I was thinking of Enterprise Objects. Core data won't easily import most existing SQL.
Instead, I would export the sqlite to csv and then use something like cCSVParse to convert to plist. Then you can read it in easily to an array or dictionary and use that to populate the core data db.
That will work easily for db's that don't depend on complex relationships. I think the future benefits of having core data will eventually easily pay for the few man hours spent converting.