I use it like this...
DB[:table].update{ :a << :a + 1 }
-> UPDATE table SET a = a + 1
(I never did like the << syntax but it worked)
and I also use it to build up updates programatically there was a
thread on that
http://groups.google.com/group/sequel-talk/browse_thread/thread/54a660568515fbb7/f2dc2b8f6e670a6f?lnk=st&q=#f2dc2b8f6e670a6f
a while back when it was introduced, and I have used it ever since.
Removing that capability is not only breaking compatibility it means I
cannot use sequel anymore :( I hope there is an alternative with a
nice syntax :)
Thanks
Jim
On Jun 29, 2:13 pm, "Aman Gupta" <[EMAIL PROTECTED]> wrote:
> > Ummm is there an alternative to the .update{ } syntax? which also
> > seems to have been deprecated? If there is it is not documented. (and
> > I use it extensively in my scripts).
>
> How do you use this? Using == for assignment feels weird:
>
> >> DB[:table].update_sql{ :a == 1 and :b == 2 }
>
> => "UPDATE `table` SET ((`a` = 1) AND (`b` = 2))"
>
> Aman
>
>
>
> > Thanks
>
> > On Jun 17, 8:10 am, Jeremy Evans <[EMAIL PROTECTED]> wrote:
> > > On Jun 17, 3:40 am, "Mark V" <[EMAIL PROTECTED]> wrote:
>
> > > > Hi,
> > > > Perhaps my understanding is stale/wrong.....
> > > > Parse-tree was removed since it used s-expressions and these aren't
> > > > available in some of the newer Ruby VM's.
> > > > A downside of this was losing Sequel filters.
>
> > > > I'm not Parse-tree guru so perhaps someone can comment on whether
> > > > "cry" could be an alternative to Parse-tree?
> >http://larrytheliquid.com/2008/06/05/learn-to-cry-by-writing-parse-tr...
>
> > > Cry is misleading in that it isn't a parse tree, because no code is
> > > parsed. You create the Cry::ParseTree objects just like any other
> > > ruby objects and you can manipulate them.
>
> > > ParseTree is deprecated and will be removed because:
>
> > > 1) It only runs on ruby 1.8, and will never work on any other ruby
> > > implementation.
> > > 2) The code is quite complex. While it works, I wouldn't be able to
> > > fix anything if it broke.
> > > 3) There is no need for it, with the expression filters introduced in
> > > Sequel 2.0.
> > > 4) It produces strings instead of ruby objects.
>
> > > Nothing is lost by the removal of ParseTree filters, except a little
> > > backwards compatibility. The expression (blockless) filters can do
> > > everything the ParseTree filters can do, and more, and faster to boot.
>
> > > Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" 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/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
