chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] A call to arms


From: Andrew Gwozdziewycz
Subject: Re: [Chicken-users] A call to arms
Date: Thu, 22 Jan 2009 15:01:30 -0500

On Thu, Jan 22, 2009 at 2:28 PM, Peter Bex <address@hidden>
wrote:> I've been there (in PHP, but still) and I am now convinced
that this
> cannot work on too big a scale.  There is a big mismatch in
> expressiveness of some systems.  For our PHP web app framework, we had
> built a system that took in abstract array expressions that encoded
> constraints, which were compiled to a SQL query for database storage,
> or to a PHP filter expression we could run on an array for session-based
> storage.
>
> This worked quite well, but we soon realised that as soon as you
> have an expression that's not supported by a storage system, you must
> then simulate it in your programming language.  When you combine this
> with OR expressions, for example, you will end up doing everything
> in the programming language:
>
> Suppose you want regex support:
> SELECT * FROM foo WHERE foo.x > 10 OR foo.y ~= /address@hidden/
> and the SQL DB does not support regexes.  Then you cannot have the
> SQL return everything where foo is > 10, and then grep the result
> set. You'd actually have to fetch the entire table and perform your
> filtering in the programming language.
>
> Of course, I don't know if this is what you had in mind, but be very
> careful when you want to do something like this. If there is a single
> thing you can express in your abstract system that you cannot express
> in even one storage layer, you're in trouble.  It gets worse when you
> consider complex joins, with conditions on both sides of the join.
> And one-to-many relations are downright evil.

Yeah, I've thought about these points and realize there isnt' a great way
to really deal with them, however, at some point you need to punt. A
library can't 'possibly deal with all possible situations the right way all the
time, and so there's compromise involved. A web framework in my opinion
is responsible for providing a smooth road for the 90% case.

This is why Rails is so popular, but Twitter complained it was too slow,
and fights "broke out" (not in the fist fight sense, but the he said/she said
blabber that occured) over it. It might not scale well for Twitter's purposes,
but for the masses who have small sites, it works perfectly fine.

So, if you have to simulate features of the storage engine to get
compatibility, all you have to do is tell users that there are some limitations
to it. Give them the information to choose for themselves. But, on the
other hand, if they end up growing significantly, and decide to switch
storage engines from ASCII files to Postgres, why should they have to do
any more than recompile/restart with a different connection parameter?

-- 
http://www.apgwoz.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]