I’m not familiar with Firebase, but I don’t think it is the same thing as sqlAlchemy. sqlAlchemy is an ORM, which gives you an object-oriented abstraction around a database using models.
Ah, that makes sense. Thanks, Justin. It sounds like you want a single network web service running (a backend powered by either Django or Flask), and for it to provide the RESTful interface to your Pyblish clients? I think.. so..? From what I gather, you can communicate directly with a running instance of a Flask server, and I was thinking “why not just pass data to it directly then?” If it isn’t meant to store real production data (as it may just be delegating out to other existing services), but you do want it to have some persistent storage, then it could use an sqlite database for storing state Using a database for data persistence is making too many assumptions. I can’t assume to have users upload their production data to a database unique to Pyblish. I’d rather have Pyblish expose data already available elsewhere, ideally reading from disk directly. In this early stage, the only information I’d like to pass along to Django/Flask are *paths* to the data I’d like it to display, along with perhaps a description of how to display it (“this is an image path”, “this is the source file” etc.) Do you think that would work? For persistence of the events themselves there might be a database or just a file. Nothing I’d expose to anyone as it would only be used in cases of Flask/Django restarting/crashing. The only other thing I could guess you might have meant was to have a local Pyblish service on each host… but I highly doubt that is something you meant. Could you expand on this? The way I pictured the communication is the same as browsing to any website. A one-off connection is made, and some data is transferred and received. There is no lasting connection between Pyblish and Flask/Django. Thanks, Marcus On 29 September 2014 09:48, Marcus Ottosson <[email protected]> wrote: > what type of communication you need from between Pyblish and Django > directly? > > I think this is best answered by the animation and description here: > https://github.com/abstractfactory/pyblish/issues/99 > > instead they both communicate to the database like this: > Pyblish -→ Database ←- Django/Flask > > Thanks Asi, this makes sense, but doesn’t this assume that this database > is used for other things, other than Pyblish and this web frontend? > > Here is how I’m picturing communication currently. > [image: Inline images 2] > > In which Pyblish doesn’t know about Flask/Django, but it’s plug-in does. > Pyblish is only running plug-ins exposed to it at run-time and has no > knowledge about what they do or how they work. This way, a plug-in can > access the surrounding pipeline, including databases. > > [image: Inline images 3] > > If I understood your description, you meant to have a database inbetween > plug-in and flask. > > [image: Inline images 4] > > The database is either unique to this particular Web Frontend for Pyblish, > but you probably meant to have Pyblish communicate with your native > pipeline database and for it to communicate with Flask. > > [image: Inline images 5] > > But wouldn’t that mean that you would have to “teach” your database about > Pyblish? For example, when Pyblish - or rather, a Pyblish plug-in - > connects and transmits information to your database, it would need to know > to connect to the running Flask instance. > > That sounds ideal if you are building Pyblish as one of your tools that > all depend on a single database. But for a standalone application that > integrates into your pipeline, don’t you think it’s better to have your > pipeline integrate at the plug-in level, and thus not require any knowledge > at all about Flask or other Frontends supplied by Pyblish? > > # Psuedo-codeimport mypipelineimport pyblish_flask > class MyPlugin(pyblish_flask.Plugin): > def process(self): > # In this case, Flask integration is hidden away and accepts > # data like a dictionary or what not. > self.notify(mypipeline.data) > > 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/CAFRtmOB%2BDONG8Xm_vBeaEtftvjU7AOWuVSs4AxPu8ofBp%3DPR8Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
