Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

jonasbn
  reversethis-{gro.napc} {ta} {nbsanoj}
http://e-diot.dk/
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Monday April 07, 2008
04:21 AM

Note on YAML config in Catalyst/DBIC context

[ #36090 ]

I am currently debugging a Catalyst application. I have run into several problems where I found the stacktrace practically useless.

The code uses InstantCRUD, which I think requires a word of warning. I should write a constructive CPAN review of this distribution in addition to mentioning it here.

Anyway, it ended up with me writing a work-around, since I could not get it too work after several attempts and different solution scenarios.

DBIC was of course swell in the end when implementing the work-around (a work around InstantCRUD that was).

The problem is actually not that the code did not work, we can fix code if we can locate the bugs. But locating bugs in Catalyst/InstantCRUD apps is not trivial. Anyway if the transaction went bad (as it did) the whole server was rendered useless and nothing else could go on until the Apache server was restarted.

So the work-around would make the imminent problem go away, but not the actual problem. I am only treating the symptoms so to speak and as a programmer that feels VERY unsatisfying.

One of my attempts was to control auto-commits in DBI. Just getting this into the connect_info part of the YAML file was quite an adventure - I hate those, they make me stray from my original goal and distract me from my current focus, this might be fun for when experimenting and hacking around, but in a w0rk situation it is not always optimal.

So if you have a YAML configuration somewhat like this:


Model::FAIadmin:
        schema_class: 'FAIadmin::DB'
        connect_info:
                - 'dbi:Pg:dbname=logicshop2faiadmin'
                - username
                - password
                - pg_server_prepare: 0

And you want to add additional DBI parameters it can be done (according to the docs), but nobody provides good examples of this.


Model::FAIadmin:
        schema_class: 'FAIadmin::DB'
        connect_info:
                - 'dbi:Pg:dbname=logicshop2faiadmin'
                - username
                - password
                - pg_server_prepare: 0
                - AutoCommit: 1

Looks quite natural and feels intuitive and you can even get ysh to eat it, but ysh knows absolutely nothing about context, more on this later.

But this does however not work, no - you have to get the last parameters parsed to a hash (I found this hint in a mail archive googling).


Model::FAIadmin:
        schema_class: 'FAIadmin::DB'
        connect_info:
                - 'dbi:Pg:dbname=logicshop2faiadmin'
                - username
                - password
                - { pg_server_prepare: 0, AutoCommit: 0 }

Anyway, ysh can really provide useful.

From the POD:

cat yaml.file | ysh | less

This can help you examine what goes on and it can help you get the right result, you still have to take context into consideration, so hints (or improved POD) can assist you here.

So now everything seems to work, but I have only made the symptoms go away - I know the problem still persists, but I do not have time to fix it now.

Anyway one of the other people involved in the application changed something in another YAML config file, and the server refused to start.

I had just introduced changes in several components late last night, so I thought I had broken something. I googled for the error message


"->config->{schema_class} must be defined for this model

and again it pointed to YAML.

I ran the YAML configs through my new toy ysh and boom. One if the files did not parse, I looked at it and I could not see any problems. Luckily the file was rather short and I remembered that my colleague had mentioned that he intended to change some values and this was the file containing the values.

Great!

So I deleted the contents and started to rebuild the file, line by line, running it though ysh after every addition and success, in the end my server would actually start.

Now I cannot remember what I fixed, I exchanged some tabs for spaces - so in order to find out I have requested the file, which might have been updated via SFTP from my colleague a hex editor comparison might be a good idea, so I know what to look for the next time this occurs, since I feel this is not the last time - perhaps we should change configuration file format?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You can use whatever formats Config::Any supports. This includes:

    * Config::General (likely to be the new "standard")
    * INI
    * YAML
    * JSON
    * XML
    * Perl

    Also, more recent versions of Config::Any (>= 0.10) will die() when a config file fails to parse correctly. This is especially helpful for YAML files as they are quite finicky.
  • I am working on a newer version of InstanCRUD. After reading this I'll consider switching to Config::General. And I'll add Autocommit by default. I've already cleaned the code somehow - and it is published at CPAN, but it is still work in progress (and the API changes all the time). I am sorry for your lost time.