Re: [RDD] Strange Grid Behaviour
On Thursday 05 December 2013 11:41:36 am Fred Gleason wrote: > An arguably better design There's a design ? Shirley, you jest !? :) -- Cowboy http://cowboy.cwf1.com Boren's Laws: (1) When in charge, ponder. (2) When in trouble, delegate. (3) When in doubt, mumble. ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Strange Grid Behaviour
On Dec 5, 2013, at 11:25 58, Wayne Merricks wrote: > Potentially to "fix" this you have a few approaches: > > * Set the initial SQL create statements to include a MyISAM table create > statement for the SERVICES table > * Refactor the SERVICES table so that there isn't 248 columns per record. Which would also break SQL portability (which I guess is not really an issue, as I am aware of no one running RD with an alternative RDBMS). > Refactoring is probably the way to go but its not a small amount of work. > Off the top of my head you could separate off all 168 clock fields into their > own table, something like: > > CLOCK_NAME: Name of the clock, same as CLOCK1 - 168 at the moment > SLOT: value 1 - 168 to replace the CLOCK1 - 168 columns > SERVICE: Name of the service this clock belongs to An arguably better design in terms of data normalization. As you observe though, it wouldn’t be a trivial amount of work. :) Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | All science is either physics or stamp collecting. | | -- Ernest Rutherford | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Strange Grid Behaviour
Hi, My understanding is something to do with a row length limit in InnoDB. If I remember correctly its because MySQL 5.5 ships with InnoDB by default as opposed to MyISAM. InnoDB has advantages in that it is supposed to be more robust in terms of not losing data in weird circumstances (power outages etc), hence the reason for the switch. Potentially to "fix" this you have a few approaches: * Set the initial SQL create statements to include a MyISAM table create statement for the SERVICES table * Refactor the SERVICES table so that there isn't 248 columns per record. Refactoring is probably the way to go but its not a small amount of work. Off the top of my head you could separate off all 168 clock fields into their own table, something like: CLOCK_NAME: Name of the clock, same as CLOCK1 - 168 at the moment SLOT: value 1 - 168 to replace the CLOCK1 - 168 columns SERVICE: Name of the service this clock belongs to Sounds simple but the amount of stuff you'd need to change (as a guess, I've not looked into the code): * Log Generation * Log Manager for the Grids * Install SQL table creation for SERVICES and a new table Theres probably a lot more that I've not thought about. By the way, even with this change SERVICES will still have 80 columns. I don't like that for readability but theres no real reason to worry about it. I quite like the way the Wordpress options table is structured with the whole: id, setting name, setting value. Plus from a programming view you can just loop through the results and shove them in a hash map for easier retrieval (instead of having a big array and having to remember element 150 = clock 69. Again this would make no difference other than to satisfy my own need for weird ways of structuring/coding things. Regards, Wayne On 2013-12-05 04:30, Karl Koscher wrote: Yeah, Ive ran in to this before as well. Which raises a point: why are service grids stored with clock names instead of IDs? On Wed, Dec 4, 2013 at 4:13 PM, Pedro Picoto wrote: I suffered the same a few weeks ago. Wayne Merricks suggested me this: Check that your SERVICES table is set to MyISAM and not INNODB (which is the default I think in Mysql 5.5+) $ mysql -h rivserver_ip_or_name -u root -p $> use Rivendell; $> show create table SERVICES; Youll get a big mess of SQL splurged out, scroll down to here: `CLOCK166` char(64) DEFAULT NULL, `CLOCK167` char(64) DEFAULT NULL, PRIMARY KEY (`NAME`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | If its not MyISAM try this: $> alter table SERVICES ENGINE=MyISAM; Then redo your grids and see if it sticks. IT WORKED! Backup the DB prior doing anything!!! ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org [1] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev [2] Links: -- [1] mailto:Rivendell-dev@lists.rivendellaudio.org [2] http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev [3] mailto:pedro.pic...@gmail.com ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Strange Grid Behaviour
On Dec 4, 2013, at 23:30 02, Karl Koscher wrote: > Which raises a point: why are service grids stored with clock names instead > of IDs? And this is a problem why? Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | All science is either physics or stamp collecting. | | -- Ernest Rutherford | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
Re: [RDD] Strange Grid Behaviour
Yeah, I've ran in to this before as well. Which raises a point: why are service grids stored with clock names instead of IDs? On Wed, Dec 4, 2013 at 4:13 PM, Pedro Picoto wrote: > > > > > > > > > > > > > > > > > > > > > > > > *I suffered the same a few weeks ago. Wayne Merricks suggested me this: > Check that your SERVICES table is set to MyISAM and not INNODB (which is > the default I think in Mysql 5.5+) $ mysql -h rivserver_ip_or_name -u root > -p $> use Rivendell; $> show create table SERVICES; You'll get a big mess > of SQL splurged out, scroll down to here: `CLOCK166` char(64) DEFAULT NULL, > `CLOCK167` char(64) DEFAULT NULL, PRIMARY KEY (`NAME`) ) ENGINE=MyISAM > DEFAULT CHARSET=latin1 | If its not MyISAM try this: $> alter table > SERVICES ENGINE=MyISAM; Then redo your grids and see if it sticks. * > *It worked!* > > Backup the DB prior doing anything!!! > > > ___ > Rivendell-dev mailing list > Rivendell-dev@lists.rivendellaudio.org > http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev > > ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] Strange Grid Behaviour
*I suffered the same a few weeks ago. Wayne Merricks suggested me this: Check that your SERVICES table is set to MyISAM and not INNODB (which is the default I think in Mysql 5.5+) $ mysql -h rivserver_ip_or_name -u root -p $> use Rivendell; $> show create table SERVICES; You'll get a big mess of SQL splurged out, scroll down to here: `CLOCK166` char(64) DEFAULT NULL, `CLOCK167` char(64) DEFAULT NULL, PRIMARY KEY (`NAME`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | If its not MyISAM try this: $> alter table SERVICES ENGINE=MyISAM; Then redo your grids and see if it sticks. * *It worked!* Backup the DB prior doing anything!!! ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
[RDD] Strange Grid Behaviour
Hi All, I've ran into a strange issue using grids in RDlogmanager. I set up a grid for generating a log for filling every day, and hour, with music. After about a week several clocks have become 'emptied'. Adding a clock into the newly vacated block will add a clock. But reopening the Edit Grid dialogue shows the hour still vacant. I've read through the operations guide, and I haven't found any leads as to what might be causing this? Any ideas? - Kurtis ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
