Class::DBI and stalinesque hiding of THE TRUTH
Matt S Trout
dbix-class at trout.me.uk
Fri Jun 23 13:51:33 BST 2006
Simon Wistow wrote:
> I have a Class::DBI app. Rewriting it in $your_favourite_orm is not an
> option. It's running on MySQL. Changing to another DB is not an option.
> These are not my rules. I am working within these constraints.
> It's a fairly standard set up - there are a bunch of Entities and
> Entities have various other attributes like Tags and Owners.
> All this is working fine.
> However I now wish to make it so that some Entities are hidden from
> general consumption based on a flag and that two different front ends
> will display the data differently.
> I'd rather not have the frontend check to see if every Entitis
> is_public() and also, when listing, say Tags, I'd preferably not like
> Tags that are attached to no public Entities to show up.
> Is there a clever way I can do this using cunning trickery? Possibly
> views or something. My DB skills are, at present, as weak as a kitten on
> Ludes who's also in traction and wasn't particularly strong in the first
> place and used to get sand kicked in its face by other, larger kittens
> when down at the kitten beach.
Yes, but it'll be a bit evil.
set_sql('Foo', ...) creates an sql_Foo class method which CDBI then calls to
Do Stuff (returning a $sth).
So, you override sql_Retrieve and friends and get them to check for your flag
(which will probably need to be local'ed if you need both behaviours in a
single process) and return a $sth with/without "WHERE minitrue_permits = 1" at
the end of it as appropriate. Persuading it to join to other tables to test
stuff as well is left as an exercise to the reader :)
Matt S Trout Offering custom development, consultancy and support
Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
More information about the london.pm