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.
On Tue, Oct 21, 2014 at 10:09 PM, Justin Israel <[email protected]> wrote: > 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: > > - https://cloud.google.com/appengine/docs/python/datastore/ > - https://cloud.google.com/appengine/docs/python/channel/ > > Or amazon > > - http://aws.amazon.com/dynamodb/details/ > - http://aws.amazon.com/sns/ > > 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 > > > > On Tue, Oct 21, 2014 at 9:43 PM, Marcus Ottosson <[email protected]> > wrote: > >> 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). >> >> # Exampledef 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* >> [email protected] >> >> -- >> 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 [email protected]. >> 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 >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOALCSxNB%2B3ZbLLLrk7_%3DjQY2nRQDiqt%3DL7X%3Dz9XBLYZAg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1VSk3jjOpSk%2BC7wrgjFFHO_6b-0-ueuxgDS3wjtsFDJw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
