Howdy just wanted to share a video series I finished up here recently. Come take a look while I demo how I create web based tools in Maya.
check out the series on my website
http://www.creativeredd.com/portfolio/development/
or check out the channel on vimeo.
https://vimeo.com/channels/672549
Great, thanks for sharing this. Maya really is a great graphics developing company and learning center, which provides youth excellent opportunity to use your creative mind in game developing area.
ok so i watched the video and ive been using stuff like this also. When watching I questioned the use of the webserver as essentially a front end to a db. And why not just query the db directly using the python bindings or PySide? I thought, wait, I use the same exact thing, “why dont I query the db directly?” So i have been having this argument in my head for the past couple of days. The only benefits I can see are:
Other benefits may be a web front end for viewing or manipulating the data, but if not, if its just a database, i’m not sure if i can justify a whole webserver just to query a db. I’m currently going over some of my own tools to see if i really need the webserver stuff or if i can get away with just connecting to the db manually.
My question to you is, how are you leveraging the webserver outside of simple db queries?
To answer your question. I recently completed the core setup of a system that would use slave machines in the system to do playblasts outside of Maya for animators.
The system, since it’s a rather large number things working together now, will check a playblast request into the db and also check to see if there is an available slave machine. When a job is completed on that machine it checks to see if there are more jobs to do and if so checks one out and continues work. The server side is handling all of this of course. The only thing the slave machine does and the user do, is check in and check out. The server is handling the flow of traffic from the different machines while making sure all of the slave machines can complete their jobs before sending them work.
The requests are all simple since all it’s doing is changing values in the db, but the server is also doing checks to make sure jobs will be completed. It does this by simply sending a request down to the slave asking if it’s alive if so, it checks the slave machine out and sends it the work. If the machine isn’t, it simply set’s the machines availability to false and moves on to the next machine in the db or just sets that jobs working status to false if there are no more slave machines available at that time.
So I do leverage the web server to handle more than just a db request, but this is a rather specialized case. But to answer some of your other questions. With a rest setup you can open your db to the web through web ports which are secure, wear as if you where directly talking to the server you’d have to open ports up to the internet and expose your sql db. It’s also extensible so it can work with just about any db so you aren’t having to learn specific sever calls and can focus on just communicating information back and forth.
Using django is nice for things like standardised auth, plus it’s inherently organized around fronting remote calls - if you did it your self (say by writing a wsgi server or similar) you’d have to do a bunch of work to do thinks like parse request URLS into commands and route them to appropriate handlers, which is all free. I run stuff on the django test server all the time, so I don’t have to worry about maintaining a ‘real’ apache server – this would not scale well for a big application used on the whole web (and I’d worry about security) but in house for dozens of users it’s not a problem… http://techartsurvival.blogspot.com/2013/12/and-i-thought-we-had-it-bad.html
I’d argue about the scalability of django… Considering sites like pinterest.com and curse.com which are developed with django. Security shouldn’t be to much of an issue too since you can tokenize your communications to the REST framework so users have to be logged in and such.
I just mean not using the wimpy test server. I don’t want to be bothered with a full Ajax setup for a few dozen users
Oh sorry I miss understood. You could us nginx instead of apache and postpresql if you ever expand. Apparently Postgres works better with django. I recently got a raspberry pi and have been wiping and configuring it while learning how to setup my own Linux server.
[QUOTE=TheMaxx;23691]
Just make sure whoever writes the code knows how it translates to SQL or you will end up with very poorly performing queries. i.e. having an ORM doesn’t mean you don’t need to understand how it works under the hood 
pro direct db access:
con direct db access:
Although, if you feel comfortable working with db records, rather than objects, you don’t need a sophisticated ORM on the server side. Just JSON encode the results of your queries and hand them back. It really depends where you plan to have the business logic - server or client side?
I would agree on all counts, but it is “easier” to write against an ORM. Obviously you’d get performance gains on pretty much all front if you did it by hand.
To counter the point against compiling libs, for 2014+, you can just use PySide and everyone has it already
I’d argue on what you consider easier or not. If django is already setup and the restful api is installed. As long as I already know the fields I want to use, I can get the models, serializer, and views view setup in around 10-15 mins and be sending data to the db through urls. Now I consider that pretty easy, just took some learning to do.
I think the rule of thumb is ORMs work better when all the work is on the client (since you can manipulate them as objects, instead of having to constantly transalate back and forth between data and object land) and pure sql works better when the hard work is on the server (since you can write fancier queries and use stored procedures)
[QUOTE=TheMaxx;23704]I would agree on all counts, but it is “easier” to write against an ORM. Obviously you’d get performance gains on pretty much all front if you did it by hand.
To counter the point against compiling libs, for 2014+, you can just use PySide and everyone has it already[/QUOTE]
I forgot not everyone is stuck in outsourcer. Most clients of us don’t seem to use 2014 yet 
I haven’t tested built in SQL connectivity in 2014 though. The C:\Program Files\Autodesk\Maya2014\qt-plugins\sqldrivers folder is pretty empty in my installation. I don’t see a libmysql.dll, and I doubt they compiled it all statically. Did you do any tests?
Distributing dlls is even more annoying though than distributing modules though, especially when you work in a shop like mine where all computers are pretty much locked down due to security reasons.
you definitely want your ORM where you do the heavy lifting. What I’m trying to setup myself is a REST API on my Apache server. Then aggregate and serialize on the server side, and de-serialize and map it to objects on the client side. With almost a dozen Maya versions in our shop I really hate distributing and troubleshooting 3rd party modules. And everyone having direct access to the Python source code and to the DB (even if it’s just for updates) doesn’t sit well with me.
I’m still torn about Django, because I got a good Apache/wsgi setup going. Django looks easy enough from the outside. But then again I’ve seen people tinker with supposedly easy Django stuff for ages…plus there’s a big support community. yeah I get it, it’s popular that’s why the community is big - or maybe people just need a lot of help to iron out.
I haven’t tested built in SQL connectivity in 2014 though. The C:\Program Files\Autodesk\Maya2014\qt-plugins\sqldrivers folder is pretty empty in my installation. I don’t see a libmysql.dll, and I doubt they compiled it all statically. Did you do any tests?
Distributing dlls is even more annoying though than distributing modules though, especially when you work in a shop like mine where all computers are pretty much locked down due to security reasons.
You are correct! I guess they opted out of that. Its pretty bare bones 