[Nitro] OG connect and exec_statement: unexpected behaviors (Critical -> Trivial)

George Moschovitis george.moschovitis at gmail.com
Sat Sep 1 05:08:55 EDT 2007


Let me have a look at your scripts.

-g.

On 9/1/07, Mark Van De Vyver <mvyver at gmail.com> wrote:
>
> On 9/1/07, Mark Van De Vyver <mvyver at gmail.com> wrote:
> > Hmm,
> > I think I've worked out what the problem is and may have a solution
> > that should also improve performance - I hope.
>
> No joy. I'm stumped.....  :(
>
> Mark
>
> > Mark
> >
> > On 9/1/07, Mark Van De Vyver <mvyver at gmail.com> wrote:
> > > Hi,
> > >
> > > I think I found some unexpected behaviors from OG - the first can be a
> > > show stopper from some.
> > > This may be specific to the MySQL and sqlite adapters?
> > > The two ruby scripts show the behaviors described below.
> > > I use the MySQL and the Sqlite adapters, could any one confirm they
> > > see the same behavior described below with another adapter - just in
> > > case.
> > >
> > > **SHOW STOPPER**
> > > 1) The Og::SqlStore#exec_statement seems to rearrange the data
> > > submitted in an sql string, and example of the original SQL statement
> > > data and the SQL statement submitted to the MySQL store follows.
> > >
> > > insert into ogmember ( address1,city,email,first_name,state,last_name
> > > ) values ( '123 High
> > > St.','Reykjavik','fred at flintstone.com','Fred','Michigan','Flintstone'
> > > )
> > >
> > > DEBUG: INSERT INTO `ogmember` (`address1`, `city`, `oid`, `email`,
> > > `first_name`, `state`, `last_name`) VALUES ('fred at flintstone.com',
> > > 'Fred', NULL, 'Flintstone', '123 High St.', 'Michigan', 'Reykjavik')
> > >
> > > **Normal**
> > > 2) In script og_create_unexpected2b.rb the DEBUG statements do not
> > > print out when running the single method in the 'Benchmark.bmbm do
> > > ..end' loop.
> > > In script og_create_unexpected2.rb I observe that the addition of
> > > another method in the benchmark loop results in the Debug code being
> > > printed.  The same behavior occurs if 5 or 5000 rows are inserted, so
> > > I don't think it is some output buffering issue - or maybe it is?
> > > The only difference in these two files is in the benchmark loop
> > > where "'create' => :create_fixture," is present or absent.
> > >
> > > **trivial**
> > > 3) Og#connect seems to make two selects from a table that has just
> > > been created.  I haven't dug in to see why, but thought I give a
> > > 'heads-up' in case they shouldn't be there.  The queries I refer to
> > > are issued from within OG#connect, the attached files should print
> > > out:
> > >
> > >  INFO: Og uses the Mysql store.
> > > DEBUG: Og manageable classes: [Member]
> > > DEBUG: CREATE TABLE `ogmember` (`first_name` text, `last_name` text,
> > > `address1` text, `city` text, `state` text, `email` text, `oid`
> > > integer AUTO_INCREMENT PRIMARY KEY)
> > > DEBUG: SELECT * FROM `ogmember` LIMIT 1
> > > DEBUG: SELECT * FROM `ogmember` LIMIT 1
> > >
> > > Using the Sqlite adapter I see something slightly different, but still
> > > the duplicate `'SELECT':
> > >
> > >  INFO: Og uses the Sqlite store.
> > > DEBUG: Og manageable classes: [Member]
> > > DEBUG: CREATE TABLE ogmember (first_name text, last_name text,
> > > address1 text, city text, state text, email text, oid integer PRIMARY
> > > KEY)
> > >  INFO: Created table ogmember.
> > > DEBUG: SELECT * FROM ogmember LIMIT 1
> > > DEBUG: SELECT * FROM ogmember LIMIT 1
> > >
> > >
> > > HTH
> > > Mark
> > >
> > >
> >
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>



-- 
http://www.me.gr
http://phidz.com
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070901/604c2ce8/attachment.html 


More information about the Nitro-general mailing list