I poked around in DataObjects, and I've seen a version where it injects
another method or two when you're using sql-specific repositories. Not hard
to do it that way. Of course nobody would want to compose raw SQL when
they're not using a sql engine.
On Tue, Sep 2, 2008 at 12:45 PM, Adam French <[EMAIL PROTECTED]> wrote:
>
> You can only please some of the people all of the time or all of the
> people some of the time. Having a way to write manual queries would
> go a long way towards supporting the use-case Daniel describes, but I
> think we need to keep in mind that DM can talk to any number of
> persistent storage schemes, not just SQL-literate ones.
>
> If we do add in find_by_sql functionality, I would suggest we call it
> find_manually or something more query language generic. It may be
> better left to a DM-More gem as well, since repository.adapter.query
> and repository.adapter.execute already exist in DM-core and all it
> would do is provide a cleaner API and fully instantiate the object
> instead of returning Structs.
>
> Anywho, my $0.02 worth.
> ===
> Adam French
> Project Manager
> Wieck Media
>
>
>
> On Tue, Sep 2, 2008 at 9:36 AM, Daniel Parker <[EMAIL PROTECTED]> wrote:
> >
> > By the way, I'm all for the new array syntax, as suggested by Yehuda.
> > If the new syntax can cover just about any complex SQL query, I
> > wouldn't mind so much being "forced" to never use SQL, but at some
> > point it translates to SQL anyway, so why not allow the programmer
> > access to that level if he wants/needs it?
> >
> > In order to get this to work for me, I had to copy the method from
> > datamapper that generates and executes the query, and I monkey-patch
> > it into a find_by_sql -- only because the sql query I needed to do was
> > too complex for the current query syntax. I don't think this use case
> > is so far out there -- plenty of people will need to execute complex
> > queries now and then -- we just have to find the right way to do it.
> > The monkey-patch I made worked great. In most cases it won't be a
> > problem (because if datamapper's migration creates the table, the
> > columns are all in the right order already), and if it is a problem
> > for someone, they can manually write the column order into the SQL and
> > it will behave as it should.
> >
> > I'd love if the new syntax was in place, but also a find_by_sql method
> > that comes with a warning: "You'd better know what you're doing if you
> > use this because you could mix up the attribute order by
> > accident." (Unless we read the column names in the query and read the
> > incoming data appropriately...)
> >
> > ~Daniel
> >
> > On Sep 2, 8:20 am, Mike Summers <[EMAIL PROTECTED]> wrote:
> >> If we get to vote on this I'd go for directly exposed SQL (why two
> >> syntaxes when one will do?) and then meta matching the result set
> >> attributes to see if they don't fit some existing model object and
> >> return as the model object rather than the array of structs.
> >>
> >> If we go with the array sytax please add AND back in. Implicit
> >> 'features' are a maintenance problem.
> >>
> >> --Mike
> >>
> >> On Sep 2, 2:57 am, mayo <[EMAIL PROTECTED]> wrote:
> >>
> >> > Would repository(:default).adapter.query(%Q{SELECT ... GROUP BY feed})
> >> > do the same job for you? This way you get an array of Structs back, or
> >> > am I missing something here? (It's pretty late, so I might be...)
> >>
> >> > mayo
> >>
> >> > On Aug 28, 10:19 am, Daniel Parker <[EMAIL PROTECTED]> wrote:
> >>
> >> > > I would like to strongly suggest that we AT LEAST devise a way to
> get
> >> > > at manually instantiating objects from sql results easier. I have
> one
> >> > > app, for example, where I have to construct a pretty complex sql
> query
> >> > > just to get the right objects, but at that point I'm grabbing whole
> >> > > records anyway, so it'd just make sense to me to be able to easily
> >> > > instantiate them into objects. I had to jump through all sorts of
> >> > > hoops to make it (my find_by_sql method) work, and then the next
> >> > > version jump of datamapper broke it. My example:
> >>
> >> > > Message.find_by_sql("SELECT messages.* FROM messages INNER JOIN
> >> > > (SELECT MAX(id) AS id FROM messages WHERE created_by =
> >> > > '#{current_openid}' GROUP BY feed) AS ids ON messages.id = ids.id")
> >>
> >> > > This basically selects the last-created message from each feed, only
> >> > > referencing one table. It worked great, and I think is a good
> example
> >> > > of something I have no other way of doing. BUT I'd rather
> instantiate
> >> > > them into objects from the sql, and not have to do it entirely
> >> > > manually.
> >>
> >> > > Is there a possibility we can at least provide a
> "not-recommended-but-
> >> > > available" way of doing it, and let developers shoot themselves in
> the
> >> > > foot until they do it right, if they want to?
> >>
> >> > > ~Daniel
> >>
> >> > > On Jul 15, 5:23 pm, Science <[EMAIL PROTECTED]> wrote:
> >>
> >> > > > Sam Smoot <[EMAIL PROTECTED]> wrote:
> >> > > > > > > Right. That back-end needs a syntax however. Otherwise we're
> expecting
> >> > > > > > > everyone's syntax plugins to manipulate the Query#conditions
> AST
> >> > > > > > > directly. Which is fragile.
> >>
> >> > > > > > > Also, I've gotta say, I'm probably speaking from a position
> of CS
> >> > > > > > > ignorance, but I have a sneaking suspicion that Ruby 1.9's
> ordered-
> >> > > > > > > hashes is one of the less good design decisions the MRI team
> has made,
> >> > > > > > > forcing a memory/computation hit, when for most uses, it
> doesn't
> >> > > > > > > matter. So MRI will be paying a penalty there for a very
> long time to
> >> > > > > > > come.
> >>
> >> > > > > > > Either way, condition order is *very* important. So unless
> someone can
> >> > > > > > > suggest a syntax that works across VMs, and preserves order,
> I'm un-
> >> > > > > > > moved from Yehuda's syntax. Plugins encouraged sure.
> >>
> >> > > > > > > -Sam
> >>
> >> > > > Sam - I brought up some related stuff on another thread but thanks
> for
> >> > > > pointing me here.
> >>
> >> > > > My opinion is that data mapper needs to support complex queries to
> the
> >> > > > extent that it permits "distributed" query building. One of the
> issues
> >> > > > I have is that building raw SQL is not very object oriented (duh)
> and
> >> > > > so in my OO architecture where different query segments are
> >> > > > constructed by various arms and legs of the objects, holding
> together
> >> > > > all the SQL is fairly difficult. I solved this problem by creating
> a
> >> > > > custom SQL object but it would be great to see Data Mapper support
> >> > > > this kind of stuff natively. The syntax sugar, ParseTree and all
> that
> >> > > > are fine but the real issue is that I need to do stuff like:
> >>
> >> > > > * create a new clause called "foo" ("or'ed" to previous clause)
> >> > > > * add several conditions to it
> >> > > > * create a second new clause "bar"
> >> > > > * add some conditions to it
> >> > > > * go back to "foo" and add some more conditions in there
> >> > > > * add two order by statements
> >> > > > * set "distinct on (x,y,z)" to the front of the select list
> >> > > > * add two more order by statements
> >> > > > * specify several table join statements
> >>
> >> > > > Being able to add SQL to the query in some order other than what
> SQL
> >> > > > expects is really the big deal for me. It lets me design my
> >> > > > application the way it "wants" to be built, rather than the way
> SQL
> >> > > > would like the output.
> >>
> >> > > > I hope this input is useful! Definitely drop me a line if I can
> >> > > > clarify anything.
> >>
> >> > > > Steve
> > >
> >
>
> >
>
--
"You have granted me life and steadfast love, and your care has preserved my
spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful
inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" 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/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
