The reason why it did it was so I could just reuse the logic that was
already there, then just bend it to change the results slightly.  But,
I can understand the logic behind not doing that.

Thanks for the explanation.

On Mar 24, 8:00 pm, Jeremy Evans <[email protected]> wrote:
> On Mar 24, 2:11 pm, dusty <[email protected]> wrote:
>
> > I'd like to give it a go with the approach you suggested.  Could you
> > explain in a little detail (or refer me to any source) that explains
> > what you mean by "no parsing SQL".  I'm not quite sure what you mean
> > by that.  Also, do you have any other policies I should be aware of?
> > I couldn't find a developer page or similar describing what they might
> > be.
>
> There's not really a lot of developer documentation, unfortunately.  I
> haven't created any formal policies, and I'm not sure if they are
> required in a project of this size, since I look over everything
> before I merge.  I'll explain the no parsing SQL with the example
> below.
>
> > > >   def self.multi_insert_ignore(*args)
> > > >     def dataset.multi_insert_sql(columns,values)
> > > >       sql = super(columns,values)
> > > >       sql[0].gsub!(/^INSERT/,'INSERT IGNORE')
> > > >     end
> > > >     multi_insert(*args)
> > > >   end
>
> Your sql[0].gsub! attempts to parse the sql that multi_insert_sql
> produces with a regular expression.  If any user uses a string like
> "\nINSERT" in one of the values of one of the inserted rows, your
> regular expression will change it to "\nINSERT IGNORE".  It's possible
> to fix your regular expression so that it will work correctly in this
> particular case (since it is very simple), but with Sequel's policy,
> the correct way is to change the multi_insert_sql method to respect a
> flag and modify the SQL produced, instead of producing SQL and then
> attempting to parse and modify it
>
> In most non-trivial cases, it is difficult to impossible to parse SQL
> correctly with a regular expression, and with good design it is never
> required.  That is why Sequel has a no parsing SQL policy.
>
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to