There exists a need to store, load, and transmit strucured data in almost any application. Te topic at hand is the consideration of a generic format. Sure, you could create a relational database, but if you're nto trying to minimize writes and adapt your application to SQL, it's waste of effort. QDataStream is close, but it results in barely usable QVariantMap structure where modifications at the leaves have to be propigated to the root. There is a need for it to be 1. Easy to use:
creation and modify: db["key"]["subkey"][i] =7;
deletion: db["key"]["subkey"].delete(i)
iteration for (const auto k: db["key"].keys()) db["key"][k]=7;
navigation: parent()/children(), maybe `jq` compatible paths, xpath? (https://stedolan.github.io/jq/)
2. Serialize:
db.save(filename)
db.load(filename)
db.stringify()
db.parse(json)
3. Supported by Qt's model/view (Now I can tie UI Models to the db)
4. Emit events on CRUD
- no events, some specific events generating emits and their specific handlers, or all events to a global handler
- now I can tie a UI elements to a spefific value in the db
- now I can QNAM POST to another server or web front end (WebSocket) on change
Just a few thoughts for what I'd like. I'm not that much inerested in serialization speed, tbh. I'd probably use a strategy to copy the database at a consistent poitn in time (no handlers running) and save that in another thread to ensure consistency. So maybe there needs to be an API for that:
snapshot = db.beginSave().waitForIdle().copy() // wait blocks external sources, not internal ones since there may be an update cascade
db.resume();
QRunnable::run(snapshot, filename, Db::save);
Just my $0.02
...
In any case, what would be the added value of Qt providing new serialization formats & APIs, especially wrt exisiting header-only libraries (rapidjson, nlohmann/json for instance in the json world) which provide better performance AND compliance than Qt's ?
...
On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira <[email protected]> wrote:
On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote:
> I’d leave XML out of this. It is difficult to integrate, as it has so many
> special features (entities, CDATA and lot of other things) making it a
> rather complex specification. But there are a couple of other formats that
> might fit a more generic data model. Yaml comes to my mind as an example,
> protobuf and flatbuffers might also be possible to stream into such a
> structure with some additional schema verification.
YAML, like CBOR, was designed with compatibility in mind. In fact, it's
designed so JSON-YAML conversion is lossless in both directions. So YAML makes
a lot of sense.
I don't know much about PB and FB, but from what I've seen it's meant to be a
serialisation format based on an IDL you describe. It's closer to QDataStream
than to JSON. From what I've seen, it makes no sense to merge those with the
other three than it does XML.
> > I'm skeptical. What do you think?f
>
> One option could also be that we have a common implementation, and then a
> very thin API wrapper for each of the formats on top that will enforce the
> format specific limitations and give you a fully typed API.
That was my original plan. The QCborValue backend can be reused for JSON as a
thin wrapper API. There's just a lot of copy & paste.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
