I think tickets 838 and 1307 apply to this already.
On Dec 1, 12:54 pm, Felix Geisendörfer <[EMAIL PROTECTED]> wrote: > Let's make this simple: Afaik CakePHP's DboSource does not support > Views, making this a request for enhancement and not a bug. This said > I'm not sure if it will be implemented because it would create > inconsistencies between the different database drivers, making > applications less portable. > > Anyway, submit a ticket if you want to get a comment from someone more > qualified on database matters then me ; ). > > -- Felix Geisendörfer aka the_undefined > --------------------------http://www.thinkingphp.orghttp://www.fg-webdesign.de > > Christoph wrote: > >> It seems to me that trying to stuff a view into the CakePHP model > >> without taking the time to add in code specifically to handle views > >> just isn't going to work, and that you should spend your energy > >> creating an object that will run the view in native SQL and return the > >> data in the format that you need. > > > This is a fair point. All the points you make are fair. But I think > > you are being a little too dismissive of database views. Yes, you can > > do the work yourself in the code. But why would you when it can be > > done so much faster and more elegantly within the database. > > >> I have never used an SQL view and would love to see a real-world > >> example of when a view should be used over, say, the CakePHP model > >> combined with associations. > > > Here is a real world example of what I'm trying to accomplish. I have > > 2 models: Users and Collections. Users hasMany Collections and > > Collections belongsTo Users. This one user has, say, 5000 records in > > the Collections table (not uncommon) with each record having having a > > variable number in the owned column. So I can let CakePHP return all > > the records and iterate through 5000 of them to get a sum of all the > > items owned in the collection or I can just create a view (that looks > > like the one I've posted several times in this thread) and have all the > > information I need returned using 1 query. I'm sure you'll admit the > > latter is significantly better than the former w/r/t performance. > > Whether it's a view or a plain SQL query doesn't matter. Yes, I could > > just do something like $this->MODEL->query( 'SELECT statement used in > > creating my view' ), but if I use that database view on various pages > > and I needed to change it for whatever reason (add/remove a field, > > etc), I have to modify all the pages where it is ues. Whereas if I set > > it up as a view, I can change the view in the database and very likely > > I wouldn't have to change the code at all. For example, let's say I > > wanted to break up 'username' into 'firstname' and 'lastname' fields. > > I could change my database view to "SELECT CONCAT( firstname, ' ', > > lastname ) as username" and not have to change my code at all. > > >> Is it a bug? Hard to say. When you use a piece of code for something > >> it wasn't intended to do and it doesn't work, is that a bug? Or is > >> that a constraint of that piece of code? > > > And yes, I may be using "...a piece of code for something it wasn't > > intended to do and it doesn't work.". "Is that a bug?", you ask. No, > > not necessarily. Admittedly, I don't know enough about the internals > > of CakePHP to know if, in fact, it is. That is why I'm putting the > > question to you guys, you who are far more experienced than I, to find > > that out. I don't want to submit a ticket saying "waah! this is broke" > > when it could just be my ignorance as to how CakePHP is _expected_ to > > function. > > > thnx, > > Christoph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
