[Maya-Python] QAbstractItemModel and Firebase

68 views
Skip to first unread message

Marcus Ottosson

unread,
Oct 21, 2014, 4:43:56 AM10/21/14
to python_in...@googlegroups.com

In QAbstractItemModel, whenever the data changes, a signal is emitted that we can listen to. E.g. when a particular field changes, the QTreeView or what have you re-draws to reflect this.

With web-applications, this doesn’t seem to be the case. Using MongoDB for instance, interacting with the model (database) typically (seems to) include an additional interaction with an event (however I’m very new to it).

# Example
def update_field(content):
    field.setText(content)  # Update visually
    database.insert({"key": value}, content)  # Update model

Firebase on the other hand looks more like QAbstractItemModel, in that for each change there is an event.

https://www.firebase.com/docs/web/api/query/on.html

firebaseRef.on('value', function(dataSnapshot) {
  // Model was updated
  field.setText(dataSnapShot.val())
});

It may be due to familiarity, but it seems more intuitive to me to listen for changes on a model, than to double-up on updating both views and models from a controller when it comes to changes to data.

Are there other databases that does this, that isn’t cloud-based? Is this a common practice? Why not?

Best,
Marcus

--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Oct 21, 2014, 5:09:43 AM10/21/14
to python_in...@googlegroups.com
Hey Marcus,

The way I see it, there is a bit of a difference between the things you are comparing. Yes, from a general perspective a model is something that stores data, but it doesn't necessarily mean that a database and a QAbstractItemModel are interchangeable concepts in a model/view situation. A database is a persistent (or not) store. Your model would wrap around that. Qt even has an equivalent concept with the QSqlTableModel. It uses abstracts an sql store and models it to provide interface-compatible data to views. 

Now, on to the part where you talk about signals and notifications of changes. It wouldn't be typical to expect to monitor signals from MongoDB in your view (mongodb doesn't even have native triggers). More realistically, you have 3 tiers: The database, the application server, and the client. It would be your application server that handles modeling the database and providing the data to the client. When data changes, it goes through the application server first. This layer allows you to emit your signals to connected clients. Some databases do have integrated notification systems (Postgres has it). And I am sure that is for specific db <-> application server situations. 

Firebase is a bit more than just a database. I would call it more like a full stack framework. It is a NoSql database, along with a scalable platform, and a flexible API. That notification feature is rolled into the package, in addition to the auth stuff. It shares some qualities with other options like Google appengine:
It comes down to the decision of whether you want to host your own services, or run them in the cloud and let someone else handle all the scalability and reliability, and just give you a full featured API. 

Does your application design include an application server? If so, I would suggest focusing on having your clients talk to one or more application servers. And let the application servers talk to the database. This insulates your clients from changes on the backend, since anything you might want to change regarding the database can remain transparent to the client code, as long as your application server continues to provide a consistent API.

-- justin



--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOALCSxNB%2B3ZbLLLrk7_%3DjQY2nRQDiqt%3DL7X%3Dz9XBLYZAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Justin Israel

unread,
Oct 21, 2014, 5:20:32 AM10/21/14
to python_in...@googlegroups.com
I didn't realize this, but Firebase is an system on top of MongoDB. They act as an application server that allows for all of the notifications when your data flows through their layer in and our of the underlying MongoDB. So really, this just goes to show that the notification layer can be at different levels. Either you are doing it in your own application layer between a database and the client code. Or you are using a service like Firebase. Or even a combination of notifications from Firebase to keep multiple application servers notified, while also pushing your own notifications to your clients.

Marcus Ottosson

unread,
Oct 21, 2014, 5:26:56 AM10/21/14
to python_in...@googlegroups.com

This layer allows you to emit your signals to connected clients.

Yeah, it was this I was trying to illustrate with the above update_field() function; that a user-event is sent to both the view, rendering the field, and the database, persisting the change; whereas in Firebase and QModel, views can instead be connected directly to the data-source (switching the name from “model” here as you said database and model aren’t necessarily exchangeable).

It comes down to the decision of whether you want to host your own services, or run them in the cloud

Do you know of a local equivalent of this? The concept of Firebase seems applicable outside of cloud-hosting, but maybe there’s something I’m missing.



For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Marcus Ottosson

unread,
Oct 21, 2014, 5:28:53 AM10/21/14
to python_in...@googlegroups.com

They act as an application server that allows for all of the notifications when your data flows through their layer in and our of the underlying MongoDB.

Ah, I see. So they are essentially doing this extra step for you, of both persisting and emitting a signal. I suppose this could be done quite simply via an abstraction/wrapper of any database with which you handle all communication to your database.

--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Oct 21, 2014, 5:43:58 AM10/21/14
to python_in...@googlegroups.com

Ya it is exactly what you would do in your own local application server layer. Theirs is just a packaged and priced service.

For the model thing though... Even the qt models don't necessarily react immediately to changes in the sql server. The model has to be told to refresh it's query or designed to know how to monitor it's data source. The result is that as soon as data changes in the model, the views will know. You can write a Qt model around a mongodb backend to provide views with instant updated but the update comes from when the model is told to query Mongo again.
Maybe that was the same point you were making. By those same standards, you could design a Qt model that abstracts a datastore that does provide notifications and have it refresh in a push fashion. But again that is all transparent to the view. Just depends on what your model is modeling.

Marcus Ottosson

unread,
Oct 21, 2014, 6:02:20 AM10/21/14
to python_in...@googlegroups.com
My point was more in favor of the web-approach.

In Qt, I'd use the signals emitted from a QAbstractItemModels to update my views, but for a web-app, this doesn't seem to be how things are normally done. At least not without Firebase or something like it. Does that sound about right?


For more options, visit https://groups.google.com/d/optout.



--
Marcus Ottosson
konstr...@gmail.com

Justin Israel

unread,
Oct 21, 2014, 2:30:42 PM10/21/14
to python_in...@googlegroups.com

A web app is just one example. Any kind of app server may or may not provide a push notification to its connected clients, and may or may not be using a database that supports push notifications.

Reply all
Reply to author
Forward
0 new messages