Class::DBI and stalinesque hiding of THE TRUTH

[Matt S Trout]

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/ +