I'm not sure I'd call 30% a modest improvement. :-) That's a huge
difference when you're talking lots of transactions.
Regarding the API, I just want to point out that 'id = :id' is not my
syntax - it's pervasive in DB adapters and ORM's alike. Hence the
reason I naively tried it in Sequel and
On Oct 12, 12:06 pm, Nate Wiger nwi...@gmail.com wrote:
I'm not sure I'd call 30% a modest improvement. :-) That's a huge
difference when you're talking lots of transactions.
I would refer to anything less than a binary order of magnitude as a
huge improvement, but I'll agree that it's more
Okay, let's say I have a model instance and I want to create a new one
from that instance. What's the best way to do this?
I tried to cheat and just change the primary key and save it again,
but that didn't work!
So, let's say... model = MyModel[1]
Now I want to save model as a new row and
On Mon, Oct 12, 2009 at 2:29 PM, cult hero binarypala...@gmail.com wrote:
Okay, let's say I have a model instance and I want to create a new one
from that instance. What's the best way to do this?
I tried to cheat and just change the primary key and save it again,
but that didn't work!
On Mon, Oct 12, 2009 at 2:37 PM, cult hero binarypala...@gmail.com wrote:
Hmmm... okay, now what if my primary key is autoincrementing?
new_model = MyModel.create(model.values.merge(:id = nil))
On Oct 12, 2:31 pm, Aman Gupta themastermi...@gmail.com wrote:
On Mon, Oct 12, 2009 at 2:29 PM,
2009/10/12 Aman Gupta themastermi...@gmail.com:
MyModel.create(model.values.merge(:id = 2))
or MyModel.create( model.values.reject{|n|n==:id} ) to let the
database set the :id
Clive
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
On Oct 12, 2:40 pm, Aman Gupta themastermi...@gmail.com wrote:
On Mon, Oct 12, 2009 at 2:37 PM, cult hero binarypala...@gmail.com wrote:
Hmmm... okay, now what if my primary key is autoincrementing?
new_model = MyModel.create(model.values.merge(:id = nil))
First, Sequel's defaults will
On Oct 12, 3:08 pm, cult hero binarypala...@gmail.com wrote:
The force encoding plugin works great when you first load a model, but
if you refresh the model (model.refresh), you lose the encoding.
Ah. That's a bug. I've got a fix which I'm testing now.
Jeremy
On Oct 12, 3:57 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
On Oct 12, 3:08 pm, cult hero binarypala...@gmail.com wrote:
The force encoding plugin works great when you first load a model, but
if you refresh the model (model.refresh), you lose the encoding.
Ah. That's a bug. I've got
On Oct 12, 1:21 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
I still think the suggestions I made in my previous post stand, with
some small additions:
1) Add support to Sequel's Oracle adapter to support bound variables
and prepared statements, using Sequel's existing API.
2) Add
Awesome. I can't rave enough about the response time on this project.
It's the best.
On Oct 12, 4:08 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
On Oct 12, 3:57 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
On Oct 12, 3:08 pm, cult hero binarypala...@gmail.com wrote:
The force
Okay, I think this is my last quandary of the day.
Although there is a .modified? method on a model, is there any way to
tell WHICH fields have been modified or is that something I'd have to
add on a plugin basis?
--~--~-~--~~~---~--~~
You received this message
On Oct 12, 1:21 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
I still think the suggestions I made in my previous post stand, with
some small additions:
1) Add support to Sequel's Oracle adapter to support bound variables
and prepared statements, using Sequel's existing API.
2) Add
On Oct 12, 4:46 pm, cult hero binarypala...@gmail.com wrote:
Okay, I think this is my last quandary of the day.
Although there is a .modified? method on a model, is there any way to
tell WHICH fields have been modified or is that something I'd have to
add on a plugin basis?
I looked through the list inside the terminal by tabbing after a model
and read through it twice and missed that. (Probably because I have 4
of my own methods that start with change.) Anyway, thanks.
On Oct 12, 4:57 pm, Jeremy Evans jeremyeva...@gmail.com wrote:
On Oct 12, 4:46 pm, cult hero
Overall that sounds good - just checked the commits, thanks for the
fast patches.
Regarding the bind_filter approach, though, I'm still not too hot on
it to be honest. I guess I don't see a case where I'd not want bind
vars when dealing with Oracle. And I also don't see how it would
handle
On Oct 12, 5:27 pm, Nate Wiger nwi...@gmail.com wrote:
Overall that sounds good - just checked the commits, thanks for the
fast patches.
Regarding the bind_filter approach, though, I'm still not too hot on
it to be honest. I guess I don't see a case where I'd not want bind
vars when
Fair enough, I'll just continue my fork for now, and if you or others
want to use it, cool. I've got other ideas on extending Sequel::Model
to improve object_id identities on multiway joins/etc so feel free to
pull anything upstream that you want.
-Nate
18 matches
Mail list logo
