I have a core data application and I would like to get results from the db, based on certain parameters. For example if I want to grab only the events that occured in the last week, and the events that occured in the last month. Is it better to do a fetch for the whole entity and then work with that result array, to create arrays out of that for each situation, or is it better to use predicates and make multiple fetches?
The answer depends on a lot of factors. I'd recommend perusing the documentation's description of the various store types. If you use the SQLite store type, for example, it's far more efficient to make proper use of date range predicates and fetch only those in the given range.
Conversely, say you use a non-standard attribute like searching for a substring in an encrypted string - you'll have to pull everything in, decrypt the strings, do your search, and note the matches.
On the far end of the spectrum, you have the binary store type, which means the whole thing will always be pulled into memory regardless of what kind of fetches you might do.
You'll need to describe your managed object model and the types of fetches you plan to do in order to get a more specific answer.
Related
I am thinking about how to best represent a certain data structure efficiently in Swift using CoreData. What I need is work with accounts (like savings, earning etc.). So what would probably make sense is an account class, where each account instance might have multiple characteristics like e.g. ACCOUNT_TYPE_ID which do not change. The core however is the VALUE attribute, which would hold the value of the account at a certain point in time. The complex thing here is that this value obviously might change over time (lets say on a daily basis, abstracting for intra-day changes) and I would need to be able to get the value of each instance for any given date. E.g. I might have my savings_private for which I would want to get the value at each month-end. This value might have changed, but as well could stay the same for various days/months. How could this most efficiently (when it comes to used space but - and that is even more important - be able to access computationally efficient) be done with a CoreData Entity/Class? I was thinking about maybe always starting with zero and then only somehow save the changes plus the date of change and then have some method for the call which would add all changes up to a date parameter - but was curious about what a best-practice might be here, as I guess I am not the first one trying to solve this.
I have been continuously changing my database structure and just can't find a good solution.
My database stores habits, each document is a different habit. The fields of the habits hold information on the habit, but where I am struggling is how to structure the completion/history.
Unlike a task, a habit is completed over and over again which means I need to store all that information and be able to query it easily for date ranges and such.
First
The first idea I had was a subcollection of documents that each held information such as the date, the completion status, etc.
Although this idea sounds good the problem was querying. I am using flutter and inside a StreamBuilder it proved difficult to access a sub-collection.
Second
My second idea was to use a document field in the habit. With this, I could have an array called completed, and the array would store a Map with the date, the status, etc.
With this idea, I made it the furthest, but where I struggle is changing the status of one field in the Map in the array.
Third
My third and most recent idea I haven't made much headway with yet but I was thinking I could use a nest Maps in the habits document field. A field called history would be equivalent to the map, then inside the Map, a date in string format would be equivalent to the Map that stores all the essential information.
This idea was great in a lot of ways, but querying the data by date range when the date is in a string format will inevitably be difficult.
Please let me know which structure is more ideal, or if there is a better way to do it. The language I am using is Flutter so I need to operate within the guidelines of the cloud_firestore package. Any help would be appreciated!
Prior to allensdk version 0.14.5, the CellTypesCache.get_cells() function returned a large, nested structure containing information about cell morphology, ephys features, location, anatomical structure, tissue donors, etc. In version 0.14.5, the structure returned is flat and much smaller.
I see that some of this information is available through get_ephys_features() and get_morphology_features(), but I'm not sure where to find the rest. Where can I go to find out how to migrate my code to the new allensdk version?
Great question. We simplified the returned dictionary from CellTypesCache.get_cells for a few reasons:
There were a large number of fields that were variously: unexplained, not useful, distracting, and/or redundant with data returned from other functions.
The way brain structures were handled made it very difficult to filter cells by cortical layer across species.
The query involved a large number of joins and was fairly slow.
(2) was probably the most urgent issue we needed to address. The new dictionary structure is explained in a bit more detail here:
https://github.com/AllenInstitute/AllenSDK/wiki/Release-Notes-(0.14.5)
You are correct that you should look for ephys. and morphology features from CellTypesCache.get_ephys_features and CellTypesCache.get_morphology_features (or just CellTypesCache.get_all_features).
If there are any fields you were using in the old dictionary structure that are not now available in the current dictionary, let me know and we can find them again.
I am working with an interesting scenario that I am not sure can work, or will work well. With my current project I am trying to find an efficient way of working with geopoints in firestore. The straight forward approach where a document can contain a geopoints field is pretty self explanatory and easy to query. However, I am having to work with a varying amount of geopoints for a single document (Article). The reason for this is because a specific piece of content may need to be available in more than one geographic area.
For example, An article may need to be available only in NYC, Denver and Seattle. Using a geopoint for each location and searching by radius, in general, is a pretty standard task if I only wanted the article to be available in Seattle, but now it needs to be available in two more places.
The solution as I see it currently is to use an array and fill it with geopoints. The structure would look something like this:
articleText (String),
sortTime (Timestamp),
tags (Array)
- ['tagA','tagB','tagC','tagD'],
availableLocations (Array)
- [(Geopoint), (Geopoint), (Geopoint), (Geopoint)]
Then performing a query to get all content within 10 miles of a specific Geopoint starting at a specific postTime.
What I don't know is if putting the geopoints in an array works well or should be avoided in favor or another data structure.
I have considered replicating an article document for each geopoint, but that does not scale very well if more than a handful of locations needs defining. I've also considered creating a "reference" collection where each point is a document that contains the documentID of an article, but this leads to reading each reference document then reading the actual document. Essentially two document reads for 1 piece of content, which can get expensive based on the Firestore pricing model, and may slow things down unnecessarily.
Am I approaching this in an acceptable way? And are there other methods that can work more efficiently?
Should I store it in a single timestamp/datetime field or separate date and time fields? I prefer to store it as a single timestamp field but I need to know when a user didn't enter a time portion.
How to best store this in the database? I'm using postgresql.
There are definitely reasons why this is a bad idea. There are also reasons why your choices are limited. It's a bad idea because it's a single data item and for the more practical reason that you can't store a timezone if you have two fields.
As mentioned above, nulls are the obvious benefit of using two fields.
You might also want to consider using a single datetime field and storing a flag to indicate whether or not the user entered a time. This could be a boolean flag. However, you will still need to think about how you are going to use this data - entering only a date into a datetime field will lead to a time component being set to midnight. This will have implications in sorting and selection. Additionally, if you are storing timezones, you will have to be very careful when you use the data.
In order to fulfill your requirement of knowing whether or not a time was entered you will need to have two fields. You do not need the second field to be a time though.
The obvious answer is to use two separate fields; then you can use NULL values.
If you choose to use one field you will need to choose a magic time part that signifies "didn't enter a real time", which has the danger of coinciding with a real time (however unlikely).
Also, if you intend to use the date and time part separately often, then it might also be convenient to use separate fields; otherwise you will often need to use selection functions for extracting the relevant part of a field.