Re: Removing Parse-tree: Should we 'Cry' ?
On Jun 29, 2:48 pm, Jim Morris [EMAIL PROTECTED] wrote:
Yep just discovered that empirically, may be nice to add that to the
cheat sheet :)
Also for the second issue this seems to work too...
Instead of...
ds.update do
periods.each do |p| # create updates for all periods
(p|idx) (p|idx) + v
end
end
This may work...
h= periods.inject({}){ |h, p| h.merge((p|idx) = (p|idx) + v }
ds.update_sql(h)
Does that look ok?
If they are all equivalent I can update.
No point in a pointless merge:
ds.update_sql(periods.inject({}){|h, p| h[p|idx] = (p|idx) + v})
I'm not sure where the idx variable you are using is defined, though.
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
Hmm that looks cleaner but gives me an error...
I left out the indexing for simplicity...
v= 123
periods= [:day, :week, :month, :year, :alltime]
DB[:stats].update_sql(periods.inject({}){|h, p| h[p] = p + v})
= NoMethodError: undefined method `[]=' for
#Sequel::SQL::NumericExpression:0xb7b289c0
Whereas..
DB[:stats].update_sql(periods.inject({}){|h, p| h.merge(p = p + v)})
= UPDATE \stats\ SET \month\ = (\month\ + 123), \year\ =
(\year\ + 123), \week\ = (\week\ + 123), \alltime\ = (\alltime
\ + 123), \day\ = (\day\ + 123)
seems to work.
On Jun 30, 7:49 am, Jeremy Evans [EMAIL PROTECTED] wrote:
On Jun 29, 2:48 pm, Jim Morris [EMAIL PROTECTED] wrote:
Yep just discovered that empirically, may be nice to add that to the
cheat sheet :)
Also for the second issue this seems to work too...
Instead of...
ds.update do
periods.each do |p| # create updates for all periods
(p|idx) (p|idx) + v
end
end
This may work...
h= periods.inject({}){ |h, p| h.merge((p|idx) = (p|idx) + v }
ds.update_sql(h)
Does that look ok?
If they are all equivalent I can update.
No point in a pointless merge:
ds.update_sql(periods.inject({}){|h, p| h[p|idx] = (p|idx) + v})
I'm not sure where the idx variable you are using is defined, though.
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
Point taken, I've been bitten by that inject typo many times, and
still make the same mistake!!
Maybe I'll remove inject from my repertoire ;)
On Jun 30, 1:59 pm, Jeremy Evans [EMAIL PROTECTED] wrote:
On Jun 30, 12:28 pm, Jim Morris [EMAIL PROTECTED] wrote:
Hmm that looks cleaner but gives me an error...
I left out the indexing for simplicity...
v= 123
periods= [:day, :week, :month, :year, :alltime]
DB[:stats].update_sql(periods.inject({}){|h, p| h[p] = p + v})
= NoMethodError: undefined method `[]=' for
#Sequel::SQL::NumericExpression:0xb7b289c0
I forgot to have the block return the new hash:
ds.update_sql(periods.inject({}){|h, p| h[p|idx] = (p|idx) + v; h})
I tend to avoid using inject in such a case anyway, as I find the
following easier to read:
h = {}
periods.each{|p| h[p|idx] = (p|idx) + v}
ds.update_sql(h)
Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
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).
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 sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
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 sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
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=stq=#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 sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
DB[:table].update{ :a :a + 1 }
- UPDATE table SET a = a + 1
These work:
DB[:table].update_sql( :a = (:a+1) )
= UPDATE `table` SET `a` = (`a` + 1)
DB[:table].update_sql( :a = 'a+1'.lit )
= UPDATE `table` SET `a` = a+1
Aman
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Re: Removing Parse-tree: Should we 'Cry' ?
Yep just discovered that empirically, may be nice to add that to the
cheat sheet :)
Also for the second issue this seems to work too...
Instead of...
ds.update do
periods.each do |p| # create updates for all periods
(p|idx) (p|idx) + v
end
end
This may work...
h= periods.inject({}){ |h, p| h.merge((p|idx) = (p|idx) + v }
ds.update_sql(h)
Does that look ok?
If they are all equivalent I can update.
Thanks
On Jun 29, 2:35 pm, Aman Gupta [EMAIL PROTECTED] wrote:
DB[:table].update{ :a :a + 1 }
- UPDATE table SET a = a + 1
These work:
DB[:table].update_sql( :a = (:a+1) )
= UPDATE `table` SET `a` = (`a` + 1)
DB[:table].update_sql( :a = 'a+1'.lit )
= UPDATE `table` SET `a` = a+1
Amand
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sequel-talk group.
To post to this group, send email to sequel-talk@googlegroups.com
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
-~--~~~~--~~--~--~---
Removing Parse-tree: Should we 'Cry' ?
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-trees-in-ruby Cheers Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sequel-talk group. To post to this group, send email to sequel-talk@googlegroups.com 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 -~--~~~~--~~--~--~---
