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?
