From: Ryan Pavlik Date: 2004-01-08T12:19:11+09:00 Subject: Re: Database applications and OOness On Thu, 8 Jan 2004 09:11:16 +0900 Tim Bates wrote: > On Thu, Jan 08, 2004 at 05:55:23AM +0900, Ryan Pavlik wrote: > > # => SELECT salesperson.name, COUNT(DISTINCT > > # transactions.customer_id) FROM salesperson LEFT OUTER JOIN > > # salesperson ON (salesperson.id = transactions.salesperson) > > # ORDER BY customers desc > Well this doesn't actually work, because the ORDER BY clause references > a column name ("customers") that doesn't exist, and also in > Criteria-1.1a at least when I tried this it failed with > NoMethodError: undefined method `join' for :customers:Symbol > from /home/tim/ruby/ln/criteria/sql.rb:243:in `_mkorder' > from /home/tim/ruby/ln/criteria/sql.rb:287:in `select' Hmm. I really need to release 1.2. You can always grab the latest from svn: http://svn.mephle.org/svn/mephle/criteria IIRC, 1.1a had a number of things in need of fixing. > I realise that these are minor things. If I can help fix them, I will - > tell me what needs to be done. I am keen to get this working. Oh, yeah, you need "COUNT(...) AS customers". Hopefully this will be fixed by 1.2 as well. > > I'm not sure what Vapor is, but---and I know you've mentioned it so > > you're aware of it---you may take a look at Mephle, since I think it > > does what you want: > > I did look at Mephle, but I seem to remember you telling me not that > long ago that it *wasn't* what I wanted. :P Oh? ;) Hrm, I probably misunderstood what you were after. > > There are a few reason I still serialize and index instead of using > > tables exclusively: > > > > 1. Some objects are large, and you don't want to index > > everything > > 2. Looking up attributes every time is slow > > 3. Not all ruby things can be represented as SQL things > > (4. SQL isn't guaranteed to be the storage mechanism, either) > > > > I'm open to suggestion though. It's conceivable that there's a > > "CachedTableObject" class or something where you give up the > > ability to write into a live system, and you avoid point 2, for > > objects that work. Of course, you still need to be able to load > > that object later, and using a unique OID for every object in the > > system is nice, so you'd still have something in the object table. > > I'm not sure what you gain by this one other than a few extra > > bytes, but it could be done. > > I'm not sure I quite follow you here. The approach that Vapor (and I > think Lafcadio) takes is to look up an attribute only when the > object is loaded or explicitly refreshed, and just keep the value in > memory, so if the same accessor method is called multiple times in > succession only one database query is made. I think this is what you > mean by "giving up the ability to write into a live system". Right. You couldn't have someone else talking to the database at the same time, at least to write. If you can't do that, I don't see what advantage it provides to store objects this way (instead of just indexing them). > Also, I'm not entirely clear on what you mean by indexing in this > context. I am very likely to set up the database tables and SQL > indexes manually, so those columns that will contain a lot of data > will naturally not be indexed. I'm not sure if you're referring to > SQL indexing though, I haven't looked that closely at Mephle. Yes, this is pretty much what I do with Mephle. Objects are stored by serializing (via Marshal) and writing that to an Object table. Anything I need for quick lookup, I stick into a table using Criteria. > Points 3 and 4 are rather moot. Point 3 because in my case I will be > careful to only put into the database that which can be represented > in SQL. I don't really want a library that hides all the SQL from > me, I know what I'm doing in that regard. Point 4 because my project > will only ever store stuff in SQL, although I realise that this is > not a reason for you to abandon that approach as I'm not the only > one who may use your library. Well, it hides the object storage bits, since they're the same for everything. Indexing and SQL stuff is abstracted via Criteria of course, but that's still "right there". Viability depends on how you want things to work, but you might check it out. -- Ryan Pavlik "Spinal hazards *are* hazardous..." - 8BT