At 04:07 PM 2/27/2002 +0000, Matt Sergeant wrote: >On Wed, 27 Feb 2002, Tony Bowden wrote: >> On Wed, Feb 27, 2002 at 11:45:03AM +0000, Matt Sergeant wrote: .... >> > Probably not, but then it doesn't provide access to certain lower-level DB >> > stuff like date formats, or optimisation. But then I haven't used >> > Class::DBI, so I couldn't say for certain. Does it, for example, support >> > outer joins? .... >> As you can write any SQL as (inheritable) class data, it will technically >> 'support' any construct you want. > >Right, so how would I go about writing an application that used Class::DBI >that absolutely needed outer joins (say, for example, a bulletin board >type application that supported anonymous postings), and I wanted it to >work cross platform?
Hi, I come from a reporting perspective. That is, the user wants to see information about products, customers, locations, etc. (i.e. various levels corresponding to business objects) by market segment, advance-purchase date, delivery date/month/quarter/year, etc. (i.e. from various perspectives or at various aggregation levels). The issues of "outer joins" and "aggregation from multiple levels of detail" cause similar problems. SQL simply doesn't support the powerful syntax needed to do what I want done. (at least without incredible amounts of pain and resorting to contorted and absolutely unportable solutions.) I personally believe that if a class "supports outer joins" or even native SQL, it does not solve my problems. I believe the solution is to implement the concepts of "outer joining" in the library/class (i.e. separate queries which are merged by the library/class). This is also the easiest way to create truly portable outer joining capabilities. I envision this capability in P5EEx::Blue::Repository. My first implementation of Entity Widgets (P5EEx::Blue::Widget::Entity::Repository?) will rely on the Repository abstraction and will benefit from these capabilities. Stephen
