PEN asked this in the Python + MXS thread, but i think this deserves it’s own. What sorts fo applications are you guys using python for in your pipelines? Why python over C++? Just kind of curious of the applications python is making in our field.
I agree Brett, this would be a better place.
I have started planning what I’m going to be doing for a client and it will be replacing a tool and system that I put in place that is all Max script. This serves the purpose for the current project that they are on but I feel it will likey start to feel growing pains at some point.
I’m looking at Python to handle a file management system for checking in and out of files. I’m thinking that it will be using a MySql data base and a Max script connection to Max for now and maybe a C++ version once I get there. Since Blur has been kind to share it’s current Python/Max plugin I’m looking at using it to make the connection instead of the com methods as it will not be needed.
So what is every one else doing?
If you are using a data base as part of the pipeline what data base are you using and why?
With Python what are the main modules that you are using that is supporting the back bone of what you have done? I ask this as it looks like there are several ways to create interfaces and connect to data bases.
Are you using other 3D apps other then Max and what are you sharing between them? ie; Geo, baked animation…
Personally, I prefer PostgreSQL, mostly because it is fully relational database, where as MySQL, the last time I looked…which has been a while, prefered to disconnect the relationships between it’s elements/tables/data and felt that this management was the responsibility of the application, not the database, which sort of runs contry to what I’ve been taught about SQL databases.
PostgreSQL allows for all the standard releationships between tables and the management of those relationships, meaning that the application writer can focus on the needs of the application and not the needs of the database as well, as the database creator will take care of these, and when you have a number of applications accessing the same database, this becomes ever increasingly important.
Again, this is just a preference.
Shane
I was told by some one reacently that there have been some significant changes in mySql, I don’t know what they were but the comment also stated that they would use it now. The person in question has written several major asset tracking systems. What would I need to find out if mySql is able to do what you said it was lacking?
As I said, it’s been 7 years since I looked at MySQL and at that time they had stated that support for internal relationships was not implemented because they believed it was the responsibility of the application and not the database to manage these relationships.
I guess the best way to find out is to know if you can create a foreign key/relationship on two tables and set up a cascade or restrict action on a record, such as delete or update.
For example. If you delete a project, you would probably want the database to automatically delete all the records associated with that project…or stop it from happening based on the business rules you have established. Either way, it’s cleaner to allow the database to take care of it.
The other thing is, that these actions should be done automatically by the database and shouldn’t require you to write your own triggers.
I took a quick look at the create table statement in the MySQL docs (5 & 6) it does appear to have foreign key constraints now…so there
edt: What’s important is that it fits your needs for the application and for your hardware…and it’s free, that always helps
edt: I’ve actually been investigating OO database, which support the concept and relationships of OO design at a native level, so that you can save and load your objects quickly and eaiserly WITHOUT first having to push them through another compiler process (which a lot of them do). I know Java and DotNet both have support for one, but I don’t know about python
So you are saying the OO database might be an option? I looked at that some time ago and thought that it was very limited, then again I don’t know much about data bases.
At the end of the day, it comes down to what your needs are.
I find it frustrating to design a OO model then try and design a relational database that fits that model, then build all the management code to "decompile" and "recompile" all that data between the two models...there is a lot of time spent building these code elements that I would prefer to spend working on designing kill apps.
I looked at couple of approaches, one was a set of wrappers that would allow you to interact with the application objects and using these wrappers, save and load them from the database. While they worked, the learning curve was step, as they wanted you to learn a new style of query language...I just want my object that has these properties... :P
They also had post-compilation actions that need to be executed in order for it to work, which is annoying to say the least…
I also investigated a pure OO database implementation, which I will have to admit, was really easy to get started and use. So for me, where I can, I prefer to use this style of system. I don't know how good it was from a speed point of view or scalability, but from ease of use, it was fantastic. I had a database which reflected my OO design, WITHOUT having to build it my self. Simple insert the object and there it was!! Add in the ability to provide abstraction and inherientcy into the model!
While it did talk about muptile user interaction and server models, I've not had the chance to test it.
This is also one strength of PostgreSQL. You can design "abstract" table structures that child tables can inheritate from without you having to do any additional management or work. When you want to insert data into the table, you just do, it is so cool
We could bounce points backwards and forwards for a long time, but if you decide Access meets your needs, then Access is probably all you will need...god help us all 8O
Shane
If you want to deal with a database with Python in an object-oriented way, I’d suggest taking a look at the SQLObject extension. It lets you use Python objects to interface with your MySQL database (or SQL, SQLite, etc), rather than through more traditional SQL queries. If SQL queries are more to your liking, MySQLdb might be better.
You should also look at the standard cPickle module, which makes it easy to save/load entire Python data structures. Normally you would do this to a disk file, but it also lets you pickle to a string. You could then save that into a single database field (using MySQLdb or SQLObject, among others).
The latter approach essentially gives you the speed and multi-user advantages of a real database, without having to deal with breaking things into database columns, etc. Obvious downside: with everything pickled into one field, you can’t do complex column queries, one of the strengths of SQL.
However, if you only want to store a few data fields per record, and you’re mainly saving/retrieving the whole record each time, that may be the way to go. It’s just a question of how you want to deal with the database in Python, and what your queries will be like.