We are unfortunately looking at migrating to sqlite from realm for which we have stuck onto ever since the first version of realm was announced in beta
This is because ours is a completely customizable app and the table coulmns required can be created by the user in a web portal and we get that via an api. With sqlite we could alter our existing table to add/delete the columns, but there is no such provision in realm.
The only workaround to this that I could find is the dynamicrealm concept. However on implementing that I lose the entire efficiency that I get with realm by maintaining the columns and values as a hashmap.
So before making the jump, want to know if realm can and will plan to provide for an equivalent support for the same
We do something similar; users can create (and remove) ‘columns’ on the fly.
We have a Realm object with a Map property that provides that functionality - which the table column ‘heading’ stored as the key and then a Realm object stores the data in that ‘column’.
Maps can be filtered and sorted using predicates so it made implementation pretty easy.
@Jay By maintaining those as a map, do we compromise anything in terms of performance? Like wanted to know if there is any overhead while accessing a column directly from the main realm table, compared to that stored in a map.
Also if there any other limitations or challenges which you faced too do let me know. Since ours is a business app with over 100 realm classes of which majority of the classes will be customizable, we are looking at future maintenance too. TIA
That’s going to be hard to answer as there’s overhead involved with anything and how much depends on the use case. For example if there are 1 thousand objects vs an object with a map property with references to one thousand objects, it’s still about a thousand objects either way.
Realm doesn’t have tables though - it’s an object database backed by NoSQL (which doesn’t have tables either). That being said, the Map property stores it’s keys as strings, so that in itself will take up space. However, we use ObjectId’s as strings which are pretty tiny so the impact is minimal.
So… maybe? probably? but is it impactful? Probably not?
It was actually pretty cool and we have not run into any issues. I would strongly suggest crafting a test app as a proof-of-concept. We built a ‘spreadsheet’ app where the user could add or delete ‘columns’ and then add data within the ‘rows’ of each ‘column’. We then used that Realm object with the Map property as the datasource for a Swift NSTableView (macOS).
Thanks for the insights @Jay . We did a poc for a minor part of our application and even though there are minor over heads(very minor), it’s still much better than sqlite in terms of read.
So let me check this in our entire application before taking a definitive call
