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. On 21/10/2014 11:02 PM, "Marcus Ottosson" <[email protected]> wrote:
> 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? > > On 21 October 2014 10:43, Justin Israel <[email protected]> wrote: > >> 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. >> On 21/10/2014 10:28 PM, "Marcus Ottosson" <[email protected]> >> wrote: >> >>> 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. >>> >>> >>> On 21 October 2014 10:26, Marcus Ottosson <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>>> >>>> On 21 October 2014 10:20, Justin Israel <[email protected]> wrote: >>>> >>>>> 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 >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1VSk3jjOpSk%2BC7wrgjFFHO_6b-0-ueuxgDS3wjtsFDJw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> *Marcus Ottosson* >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> *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/CAFRtmOD%2BwxhGTqve%2ByjrsF-y08H3L0Y-ATjFE2RhYgs9fALuqQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD%2BwxhGTqve%2ByjrsF-y08H3L0Y-ATjFE2RhYgs9fALuqQ%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/CAPGFgA369rb3J3CHgT0J43xsaure8aJ7VgoQeFKoFNqEkdQDNA%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA369rb3J3CHgT0J43xsaure8aJ7VgoQeFKoFNqEkdQDNA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *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/CAFRtmODUDu54DtV2xrQUn9FxBiP4ZhhOSyLcoa6p24cMcCkKhQ%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODUDu54DtV2xrQUn9FxBiP4ZhhOSyLcoa6p24cMcCkKhQ%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/CAPGFgA31-YRzB_1QeS8NESkPx7WOmNRj5eX5JFFdGvSrgp9yGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
