What I think about having a disparity with the data structure and the folder structure is that you can do it in to some level, but then you shouldn't do it as much as to make it completely irrelevant from one to the other.
Your starting point of having a flat structure is because of your old implementations heavily non-flexible design, and your direction of adding an abstraction layer is not correct. You are trying to solve a problem by creating a bigger one, trust me. Let me explain what I think is a better approach. 3 years ago I was doing it with XML files. Now switched to a SQL database and written a library called Stalker which is basically a Production Asset Management Library written completely in Python and it is OpenSource with LGPLv2 license. I need to explain it over Stalker cause it is what I came along with while thinking about the same problem. At this point I suggest reading the tutorial page of Stalker which explains all the idea behind Stalker in a smooth way, so please visit: http://pythonhosted.org//stalker/tutorial.html#part-vi-asset-management So, in Stalker the base data is "Task" (actually everything starts from SimpleEntity). And all the Assets, Shots or Sequences are derived data types. Tasks can be hierarchically grouped with a parent/child relation. You are not forced to have Shots stored under Sequences nor Assets under anything. You can freely create your own structure. And also the folder structure is not forced to be forced to reflect the parent/child relation of the Tasks/Assets/Sequences/Shots. You can freely define them by using per project and per data type Jinja2 templates. In Stalker you can have an Asset under a Shot or a Shot under an Asset or let say a Shot under a Sequence or you can have a Task which is not an Asset or Shot but something that needs to be done and it is related with one or more files on disk. Every project has its own structure or you can share ``Structure`` of one project with another. Also every project can be stored in a different placement which is called ``Repository`` in Stalker. Back to your question, I don't think it is a good idea to use a completely irrelevant folder<->data structure, just to avoid having a constant/inflexible structure on all of the projects where things get unnecessary, the solution I think is just to make it flexible enough so you can have different project structures per project. I hope my answer was helpful. On May 9, 2014 5:18 PM, "Fredrik Averpil" <[email protected]> wrote: > Sounds like a schema to me! It concretely describes the projects layout >> and what it must conform to. >> > > Hehe, ok I just never heard that term before :) > > > // Fredrik > > -- > 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/CAD%3DwhWN_Ty06fzm_jqpMaRdmA2CkVL06%3Due9QmNkHTdVDTrTNw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWN_Ty06fzm_jqpMaRdmA2CkVL06%3Due9QmNkHTdVDTrTNw%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/CAGNmyx4nHz8aXOXyfH0Mw1mPXtrFj%2BVTPOjGSicQ3EL2eMyEfw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
