Your Mother has asked for the wisdom of the Perl Monks concerning the following question:

So, dates. I mean, dates. Right? Stupid Earth doesn't have the decency to revolve and rotate in 10s. And be flat.

I'm starting a little (real world) job dispatch + scheduling app with Catalyst; like many others (locations, users, times, frequencies, free/busy slots for locations and users). My question is probative, data design phase. I do not believe there is anything quite like what I'm doing but I'd love to hear if there is freeware out there to do job dispatching (again this is for the real world; taxi driver, copier repairman, plumber kind of thing where you have to send an agent to a location on an arbitrarily complex schedule).

Scheduled dates (duration, frequency, coincidence like busy/free) are decidedly non-trivial. I'm considering using iCal formats in DB fields. The problem being, the relational aspect just went out the window; you have to read in all possibly related records, vivify them as some kind of iCal object, and then check for conflicts, availability, repetition... So, this strikes me as bad idea but an even worse one is trying to reinvent a date duration/frequency syntax.

Thinking out loud and would appreciate same; any input, guidance, horror stories. I will open source the project if I can write it well enough (clean code + generalizing it well).

  • Comment on Scheduling/dates design -- iCal + RMDBS? Or...?

Replies are listed 'Best First'.
Re: Scheduling/dates design -- iCal + RMDBS? Or...?
by shmem (Chancellor) on Nov 24, 2007 at 00:04 UTC
    iCal format in DB fields? I guess you are not scheduling past dates, and I guess (I might be wrong) your dates don't survive the 32 Bit timestamp overflow. I'd store a timestamp (as GMT, seconds since epoch) and an offset in the DB (for duration) and then (depending of the scope of the application) some attributes, like timezone, DST begin/end etc and implement all conversions with a CPAN module (myriads of Date stuff modules, pick one.)

    But iCal format in DB fields? *shudder* I guess your app would spend lotsa time in some conversion sub.

    --shmem 

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
[reply]

      I shudder as well. Just having a hard time thinking of how to best do parts of this (especially frequency) without riding a scheduling grammar. Crontab grammar is fairly powerful too...

[reply]
Re: Scheduling/dates design -- iCal + RMDBS? Or...?
by tachyon-II (Chaplain) on Nov 24, 2007 at 13:22 UTC

    As shmem points out storing iCal data in a database is a rather silly idea. iCal is a data exchange format, and is not a sensible way to store dispatch data if you want to be able to rapidly perform calculations as all you can get the database engine to do is cough up data which you must then parse into a useful internal format for manipulation. You can not avoid the fact you need this internal representation for you calculations so just store it, preferably in a well indexed way that lets you get maximum mileage out of the DB engine.

    In terms of development I would suggest putting aside all your ideas about generalizing it well and open sourcing it (noble as they may be) and look at an "agile software development" model and write some simple code that actually does something rather than some complex code that might do everything for everyone.....eventually.

    You may save yourself a lot of time by looking into rostering software

    cheers

    tachyon

[reply]

      Good advice, thanks. Ironically, it's how I already solved a few other parts. My first schema was much bigger and clumsier than after I took a higher view -- divorcing myself entirely of the initial target case -- to abstract the elements and write a bunch of story cards for the application. I think I dropped about five tables and several redundant, or ass-backwards foreign keys. I'm writing failing tests right now based on the story cards. Really trying to follow best XP for a change and see how the experience differs from some past projects. :)

      Last night I realized I had abstracted things apart correctly except for frequency. A single "job" shouldn't own/know its frequency but that's where I had the data living. Moving it out simplifies everything; and allows for smooth higher abstractions if API guts change b/c of shoddy, I mean sub-optimal, early choices.

[reply]

Back to Seekers of Perl Wisdom