I am using a Closed range e.g let ageRange = ClosedRange(18...45)
What is the best way of saving this to Firebase DB? Do I need to save the lower and upper bound separately?
Thanks
The Firebase Database can only store JSON types.
Since ClosedRange is not a JSON type, you'll have to find a way to convert it back and forth.
Two common ways to do this:
Store it as a single string
Store its constituent parts
The first one is often easiest. But the second option has the advantage that you can query for its parts.
Related
I'm using Azure Data flow to do some transformation on the data but I'm facing some challenges.
I have a use case where I have two streams, these two streams have some common data, and what I'm looking for is to output the common data between these two streams.
I do matching data with some common fields(product_name(string) and brand(string)), I have not got ID.
to do the matching, I picked lookup activity and I tried to compare the brand in the two streams, but THE RESULT IS NOT CORRECT because for example:
left stream : the brand = Estēe Lauder
right stream. : the brand = Estée Lauder
for me this is the same brand, but they have different text format, I wanted to use 'like' operator but lookup activity does not support it, I'm using '==' operator to compare.
is there a way to override this problem please ?
If you use the Exists transformation instead of Lookup, you will have much more flexibility because you can use custom expressions including regex matching. Also, you can look at using fuzzy matching functions in the Exists expression like soundex(), rlike(), etc.
I want to store only one value per attribute in Xcode
If a new value is stored then I want to overwrite the first on, to keep only one value
one attribute = one value
Is there an option for that ?
Or should I delete existing value before storing the new value ?
(I learn core data, I may not use it right...)
If your data really only consists of single key-value pairs I would make use of UserDefaults and not core data. Specially if the data is rather simple and not "interacting on each other". The documentation can be found here UserDefaults doc, for examples see UserDefaults in Swift 4
I would like to perform a Swift sort on a Realm Results container like
let swiftArray = realm.objects(Parent).sort{$0.children.count > $1.children.count}
Would it be possible to convert swiftArray back to Results<T>? The rest of my code works with Realm containers and converting everything to Swift arrays will probably reduce performance.
Or, even better, would it (ever) be possible to use Swift sort methods directly on Realm containers?
Unfortunately, that's not possible at the moment. Ideally, you would be able to sort the items via Realm using .sorted("children.count"), but at the time of writing, Realm doesn't support key path sorting.
There's an issue on the Realm GitHub account tracking this issue. Please go there and +1 it to let the other Realm engineers know you want it. :)
If your current solution where you're creating a manually sorted Swift array isn't acceptable, something you could consider doing is adding another property to your Parent model object called numberOfChildren and store the children count there. While this does mean making your data slightly redundant and increasing maintenance a bit, you could then use that property to sort your results while keeping it entirely within Realm. :)
Consider following two collections and followed note. Which one do you think is more appropriate ?
// #1
{x:'a'}
{x:'b'}
{x:'c'}
{x:['d','e']}
{x:'f'}
.
//#2
{x:['a']}
{x:['b']}
{x:['c']}
{x:['d','e']}
{x:['f']}
some facts:
field x have usually only one value (95%) and some times more (5%).
Mongodb behaves with {x:['a']} like {x:'a'} while querying.
MongoVUE shows scaler values in #1 directly and shows Array[0] for #2.
Using #1, when you want append a new value you have to cast data types
#1 May be a little faster in some CRUD operation (?)
To amplify #ZaidMasud's point I recommend staying with sclars or arrays and not mix both. If you have unavoidable reasons for having both (legacy data, say) then I recommend that you get very familiar with how Mongo queries work with arrays; it is not intuitive at first glance. See for example this puzzler.
From a schema design perspective, even though MongoDB allows you to store different data types for a key value pair, it's not necessarily a good idea to do so. If there is no compelling reason to use different data types, it's often best to use the same datatype for a given key/value pair.
So given that reasoning, I would prefer #2. Application code will generally be simpler in this case. Additionally, if you ever need to use the Aggregation Framework, you will find it useful to have uniform types.
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.