On 2/5/07, Ben Sizer <[EMAIL PROTECTED]> wrote:
On Feb 5, 8:01 am, "Jorge Vargas" <[EMAIL PROTECTED]> wrote:
> On 2/5/07, tamara6 <[EMAIL PROTECTED]> wrote:
>
> > So something that actually had me hung up for a long time was how to
> > do something like this:
> > "select * from Someplace where something like '%word%' "
>
> > The Django docs show how to do this clearly with the keyword
CONTAINS
> > and shows the SQL equivalent.
>
> that is a common misconception of ORM I have to agree that SO takes it
a
> little to far into the Object part but you need to stop thinking of
queries
> that is not how a ORM is supposed to work, you don't do select * or
select
> col1,col2,col3, you ask for the object Foo and it will return that
object
> you will ask for all objects of type foo that have lastname = var.
that is
> the reason why some "obscure" feature of SO are in the sqlbuilder
stuff.
> I'll make a note for the FAQ for this. way to many people want to use
SO as
> a query language when it's point is that it isn't in fact I believe
this is
> the main reason people like SA better and not more valid ones like
less
> queries and more flexibility on table creation.
It's not that people want to use the ORM wrongly, it's that they have
a certain task they want to perform, they know the 'old' way of doing
it, and need to find the new equivalent. It's a problem they can
clearly express in SQL, so that's a reasonable starting point. The
docs therefore should clearly show the equivalent of common SQL
expressions.
yes but that is not the goal of SO, SO was build so you don't have to. So
I'm not sure if we should promote things that it is not supposed to do like
doing select a,b,d from f
It's ok for there to be problems that are hard to solve. It's not ok
for there to be problems that are easy to solve in SQL but not with
SQLObject. That is a backwards step for most developers. Common SQL
use cases need SQLObject equivalents documented for use. Otherwise,
SQLObject is a burden, not a benefit.
I agree but this is exactly the place where people don't like SO and the
main reason the switch to SA is happening, you could even say that SO is too
much magic, this is one of the reasons "newbies" like SO a lot but
experience developers find SO a bit restrictive.
Above, you mention "you will ask for all objects of type foo that have
lastname = var", but the original poster did want something very
similar: "ask for all objects of type foo that have lastname LIKE
var". This seems reasonable to me, providing the database supports it,
since I don't think anybody can argue that selecting every object
individually and then querying that field manually in Python is
acceptable in most applications.
yes but again SO wasn't designed for that the sqlbuilder was something added
later in order to fix some of the problems SO had, now you have to remember
that at the time TG was born this was the best we had and I'm sure Kevin
knew some of it's limitations, then came the SQLObject2 and SQLAPI ideas but
sadly that is vaporware, and then we had this shiny new project call SA that
does everything SO2 and sqlapi promise but it's still inmature, for example
porting from SA0.2 to SA0.3 was a big change in API which broke TG, so we
are not moving to SA but not there yet. What I want to say with this is that
we are aware of the situation we know there is a problem but it seems to be
the concensus that it's better to move to SA then "fix SO" either at the
docs or code level.
--
Ben Sizer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
