Re: Database applications and OOness

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
> 
> Granted, it doesn't generater column headings, and you currently have
> to use a literal string hack to get the SQL function.  This should
> hopefully be fixed before long.

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'

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.

> 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

> 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".

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.

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.

Tim Bates
-- 
[e-mail]