Skip to content

Latest commit

 

History

History
194 lines (135 loc) · 7.67 KB

TODO.rst

File metadata and controls

194 lines (135 loc) · 7.67 KB
Raw

TODO

  • Update: Better support duration Tasks.

    The current status workflow is not working with duration based tasks. Task statuses should be updated automatically for duration tasks according to their computed start and computed end date values.

  • Auto history generation.

    Automatically record all kind of CRUD actions to create a history for any attribute present in an entity.

  • SCM Integration:

    The repository can be a local path, and the project can be managed with an SCM, preferably with Mercurial.

  • Per user settings file:

    To let Pipeline TDs easily setup a new workstation with a setup script, a predefined file let say with a name of ".strc" can be placed in to the users home folder and Stalker can search for this file and parse it to get things like the database server path, user name and the password.

    There could be also an $STRC environment variable which is showing a common place lets say in the fileserver, which also may have a ".strc" file. In this way it will be easy to setup only one ".strc" file for the whole studio.

  • __tablename__ and __mapper_args__:

    The duty of the __tablename__ and __mapper_args__ variables are very common to any class in the SOM. It can be gathered in a mixin and the :class:`~stalker.core.models.SimpleEntity` can be mixed with this class and the rest will have their table name and polymorphic identity by default.

  • use pyseq for file sequence handling:

    PySeq is a great, simple library which handles all the file sequence actions. It would be great to use it in the :class:`~stalker.core.models.Link` instances. So, the :class:`~stalker.core.models.Link` class can also hold a string which can be uncompressed with the pyseq.uncompress function:

    from pyseq import uncompress
seq = uncompress("./tests/012_vb_110_v001.%04d.png 1-10",
                 format="%h%p%t %r")

  • Hidden keyword arguments:

    Because of the heavy inheritance, it is not very clear what parameters are needed to initialize a class. A simple solution is to repeat all the parameters of the inherited class in the __init__ of the child class.

DONE

  • Update error messages:

    Not all error message are clear. Generally, because of the heavy inheritance, it is not very obvious which class gave the error. Writing down the class name should help the user to understand at least what class is giving the error message.

  • Drop support to any database other then PostgreSQL.

    This is needs to be done mainly to benefit from a system that is highly optimized for one database in mind. There are some certain functionality that is only supported in PostgreSQL and will make Stalker better but break the compatibility to any other DB. Also trying to support SQLite3 with its lack of support to some key functionality stabs Stalker in back.

  • Test CRUD:

    The database tests should test if all the Create, Read, Update and Delete operations are happening properly.

  • Plural name:

    The plural name attribute needs to be reintroduced.

  • datetime instead of date

    In the Task class all the time calculation should be done over the datetime.datetime class instead of datetime.date object. This will let us to increase the granularity of the scheduling.

  • end_date attribute in DateRangeMixin:

    there could be a synonym for the due_date attribute in the :class:`~stalker.core.models.DateRangeMixin`. Which will be meaningful for :class:`~stalker.core.models.Booking` class.

  • Logging:

    Use the Python logging module to output Debug messages.

  • StatusMixin and string indices:

    StatusMixin should be able to set the status with a string, because it is possible to use strings in StatusList.

  • Start & End Date For Classes Mixed With TaskMixin:

    All the classes which are mixed with TaskMixin should have a start and end date attribute which will be set to the start date of the first task to the due_date of the last task.

  • Refactor target_entity_type attributes

    StatusList, FilenameTemplate and Type classes are using the same target_entity_type attribute, create a mixin for that.

  • OverBookingWarning:

    Create a new Warning for the :class:`~stalker.core.models.Booking` class which will be emitted when a resource is booked for the same time period more than once.

  • Auto StatusList connection:

    StatusLists can be automatically connected to the created instance if there is already a database setup and a StatusList instance already defined for the current class. This means mixing the model part with the control part but it is acceptable.

  • Stop the fight between SimpleEntity.name and SimpleEntity.code.

    Currently name superseeds code, but it is annoying to change the code over and over again just because the name is changed. So change the behaviour to something like that; the code is only updated to the same value with name if it is set to None or empty string. In any other case the code should remain in the same value.

  • SQLAlchemy ORM Declarative:

    Use declarative for the whole system. It started to make no sense to use classical approach with Python objects and it started to be very hard to try to update all the relations which is handled automatically by SQLAlchemy. Besides, the work done by all the attributes which are using ValidatedList is replaced with a neat system whenever the mapping has occured. Which is the usage case %90 of the time.

    Tests are going to be nearly the same. The only programming overhead is the implementation itself.

    Mixin classes also needs some attention, but as far as I see it is successfully handled withing declarative approach.

  • "__stalker_version__" in SimpleEntity:

    Create an attribute called __stalker_version__ in the SimpleEntity, and automatically update it to the current version string of Stalker to be able to see with which version of Stalker this data is created, mainly important for the database part.

  • Replace all the Mocker based tests with Unittest's which are using real objects. It was necessary to use the Mocker library while designing the rest of the system, but it is now making things complex and started to hide the changes of one object from the others in the system.

  • Convert all the list comparison test to assertItemsEqual

  • Add a slot in the ValidatedList which will hold the callable for the validation process when any of the objects are changed (set, remove, delete etc.) to allow the callable to be called when something has changed. This will allow more control on the list, e.g. this will help controling the relation of the classes to each other.

  • Check FilenameTemplate class documentation.

  • Check database part of all the previous Type dependent classes (Link, Asset, Project, Task)

  • Update the exceptions. Check if a proper exception is raised instead of raising ValueErrors all the time.

  • A Status in StatusList should be accessed by its name used as the index

  • A status should be comparable with a string like project.status=="complete" or project.status=="cmplt"

  • for an object which stores a list of other objects, stalker is validating if the list is gathered from the correct type of objects, for example, StatusList objects only accepts a list of Status objects. Stalker is able to check if the elements in a list are Status objects when a list is assigned to the StatusList.statuses attribute, but it can not check anything if the list element is changed individually afterwards. This behaviour should be extended with a validating system which is able to track changes on list elements.

    SOLUTION:

    Added the ValidatedList list variant which does all the necessary things explained in the problem.