From Reid.Thompson at ateb.com Mon Jun 4 14:52:00 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Mon, 04 Jun 2007 14:52:00 -0400 Subject: [Nitro] Request for Transaction example Message-ID: <1180983120.20824.15.camel@jhereg> For a simple example's sake, assume i have a file in which space delimited data correlates to an Og table. The file has +2 Million rows. How do I setup a transaction to handle the entire file? I tried something like below, but I think it is committing on every line, rather all as a transaction... ( Postgresql ). .... db = Og.setup(og_psql) store = db.get_store store.start myfile = File.open("/home/rthompso/reid") myfile.each_line {|line| date, ts, type, telno,t2, location, calltype, fa, fn, result = line.split(' ') tbl = Loadtbl.new tbl.date = date tbl.ts = ts tbl.type = type tbl.telno = telno + t2 tbl.location = location tbl.calltype = calltype tbl.fa = fa tbl.fn = fn tbl.result = result tbl.save } store.commit .... Thanks, reid From john at oxyliquit.de Mon Jun 4 16:22:07 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 04 Jun 2007 23:22:07 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1180983120.20824.15.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> Message-ID: Hi, Loadtbl.transaction do |store| > myfile.each_line {|line| > tbl = Loadtbl.new > tbl.save > } end Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Mon Jun 4 16:23:49 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Mon, 04 Jun 2007 23:23:49 +0300 Subject: [Nitro] George: annotation :text_key Message-ID: Hi George, sorry for destroying your text keys last time. :P def load(pk) if (key = ann(:self, :text_key)) && pk.to_i == 0 && (pk !~ /\S{22}/) I think however that there might be potential problems which could confuse unknowing users. * any pk with more than 22 consecutive non witespace chars + text key (that regex should really be /\A\S{22}$\z/ if at all) * Tag['1.41'] meaning the to_i is potentionally shadowing some values and will raise a not meaningful DB error (string not applicapable for integer column) and at seemingly 'random' values. * OgKlass[request['oid']] meaning a string could be passed from someone who doesn't know, which all satisfies that, but still is wrong because the primary key of OgKlass is a text key itself, maybe containing "0 Cool". This is the three ways I think this method could go wrong (besides it using 'unnecessary' annotations). But then, this is only theoretically, as this is is a toally undocumented feature which only can be found by RTFS'ing and is solely used in Taggable (and even there undocumented). So I guess this has its point, as it's only used by a single person who knows what he's doing. ;) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From Reid.Thompson at ateb.com Mon Jun 4 16:34:57 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Mon, 04 Jun 2007 16:34:57 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> Message-ID: <1180989297.32064.4.camel@jhereg> On Mon, 2007-06-04 at 23:22 +0300, Jonathan Buch wrote: > Hi, > > Loadtbl.transaction do |store| > > > myfile.each_line {|line| > > tbl = Loadtbl.new > > tbl.save > > } > > end > > Jo > Ok mod'ed to... db = Og.setup(og_psql) store = db.get_store myfile = File.open("/home/rthompso/reid") Loadtbl.transaction do |store| myfile.each_line {|line| date, ts, type, telno,t2, location, calltype, fa, fn, result = line.split(' ') tbl = Loadtbl.new tbl.date = date tbl.ts = ts tbl.type = type tbl.telno = telno + t2 tbl.location = location tbl.calltype = calltype tbl.fa = fa tbl.fn = fn tbl.result = result tbl.save } end It still appears to be committing on each save -- if all records were in a single transaction, no rows should be present until the final commit -- correct???? yet... rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 31692 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 32055 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 32293 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 32611 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 32985 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 33431 (1 row) rthompso at jhereg:~$ psql -U rthompso -c "select count(*) from tbl4" test count ------- 33883 (1 row) From john at oxyliquit.de Tue Jun 5 01:26:38 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 08:26:38 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1180989297.32064.4.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> Message-ID: Hi, > It still appears to be committing on each save -- if all records were in > a single transaction, no rows should be present until the final commit > -- correct???? > > yet... that I don't know, have you watched the sql output? That's the best way to make sure everything's alright. `$DBG = true` somewhere above Og.start will do. With 32k entries it'll be a little messy, but you can redirect your output to a file I guess. :) So, the first sql statement (after starting up Og) should be a begin transaction. There's all kinds of transaction 'levels', read http://www.postgresql.org/docs/8.0/static/transaction-iso.html for more information. It says 'read committed' is the standard level, but it might be uncommitted for you, if you can select stuff while transaction is still in progress. But, if there's no TRANSACTION at the beginning, then there's something wrong within Og. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From janm-nitro at transactionware.com Tue Jun 5 02:43:55 2007 From: janm-nitro at transactionware.com (Jan Mikkelsen) Date: Tue, 05 Jun 2007 16:43:55 +1000 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> Message-ID: <4665062B.9010104@transactionware.com> Jonathan Buch wrote: >> > > It still appears to be committing on each save -- if all > > records were in >> > > a single transaction, no rows should be present until the > > final commit >> > > -- correct???? >> > > >> > > yet... Yes, that is correct. > > [ ... ] > > There's all kinds of transaction 'levels', read > > http://www.postgresql.org/docs/8.0/static/transaction-iso.html > > for more information. It says 'read committed' is the > > standard level, > > but it might be uncommitted for you, if you can select stuff > > while > > transaction is still in progress. Postgresql doesn't have dirty reads: read uncommitted is turned into read committed. Regards, Jan. From john at oxyliquit.de Tue Jun 5 02:56:22 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 09:56:22 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <4665062B.9010104@transactionware.com> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <4665062B.9010104@transactionware.com> Message-ID: Hi, > Postgresql doesn't have dirty reads: read uncommitted is turned into > read committed. yes, thank you, I read that too after sending that mail. ^^; Sorry for spreading false information. :P Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Tue Jun 5 03:49:26 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 5 Jun 2007 10:49:26 +0300 Subject: [Nitro] George: annotation :text_key In-Reply-To: References: Message-ID: Hello Jonathan, thanks for pointing out these problems. Can you suggest a better solution or do you suggest that I remove this feature from the public version of Og altogether? -g. On 6/4/07, Jonathan Buch wrote: > > Hi George, > > sorry for destroying your text keys last time. :P > > > def load(pk) > if (key = ann(:self, :text_key)) && pk.to_i == 0 && (pk !~ /\S{22}/) > > I think however that there might be potential problems which could > confuse unknowing users. > > * any pk with more than 22 consecutive non witespace chars + text key > (that regex should really be /\A\S{22}$\z/ if at all) > * Tag['1.41'] > meaning the to_i is potentionally shadowing some values and will raise > a not meaningful DB error (string not applicapable for integer column) > and at seemingly 'random' values. > * OgKlass[request['oid']] > meaning a string could be passed from someone who doesn't know, which > all satisfies that, but still is wrong because the primary key of > OgKlass is a text key itself, maybe containing "0 Cool". > > This is the three ways I think this method could go wrong (besides it > using 'unnecessary' annotations). > > But then, this is only theoretically, as this is is a toally undocumented > feature which only can be found by RTFS'ing and is solely used in > Taggable (and even there undocumented). > > So I guess this has its point, as it's only used by a single person > who knows what he's doing. ;) > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.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/20070605/d4633e7c/attachment.html From john at oxyliquit.de Tue Jun 5 04:16:19 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 11:16:19 +0300 Subject: [Nitro] George: annotation :text_key In-Reply-To: References: Message-ID: Hi, > thanks for pointing out these problems. Can you suggest a better > solution or do you suggest that I remove this feature from the > public version of Og altogether? I'm actually not sure, I just wanted to bring this to attention before a greater audience. :) I know not many will care either way, but I love to be proven wrong and greater exposure is always good. :P I pondered this, and see no better solution, I guess this is as good as it gets. I myself always use 'adapted' Og repos, so either way is good for me, but other people aren't as source crawling as I am and might actually like that :key feature, or would love to have that extra little bit of speed by removing the ann call. So, anyone care enough to jump in and say something? Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Tue Jun 5 05:26:13 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 5 Jun 2007 12:26:13 +0300 Subject: [Nitro] George: annotation :text_key In-Reply-To: References: Message-ID: I too think there is no easy solution, and I really like this feature. It allows code like Category[1] and Category["News"] to work at the same time... but as you mentioned you have to be a little careful... -g. On 6/5/07, Jonathan Buch wrote: > > Hi, > > > thanks for pointing out these problems. Can you suggest a better > > solution or do you suggest that I remove this feature from the > > public version of Og altogether? > > I'm actually not sure, I just wanted to bring this to attention > before a greater audience. :) > I know not many will care either way, but I love to be proven wrong > and greater exposure is always good. :P > > I pondered this, and see no better solution, I guess this is as > good as it gets. > > I myself always use 'adapted' Og repos, so either way is good for > me, but other people aren't as source crawling as I am and might > actually like that :key feature, or would love to have that extra > little bit of speed by removing the ann call. > So, anyone care enough to jump in and say something? > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.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/20070605/cfd32380/attachment-0001.html From Reid.Thompson at ateb.com Tue Jun 5 09:08:21 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 09:08:21 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> Message-ID: <1181048901.2613.27.camel@jhereg> On Tue, 2007-06-05 at 08:26 +0300, Jonathan Buch wrote: > Hi, > > > It still appears to be committing on each save -- if all records were in > > a single transaction, no rows should be present until the final commit > > -- correct???? > > > > yet... > > that I don't know, have you watched the sql output? That's the best > way to make sure everything's alright. `$DBG = true` somewhere above > Og.start will do. With 32k entries it'll be a little messy, but you > can redirect your output to a file I guess. :) > So, the first sql statement (after starting up Og) should be a begin > transaction. > > There's all kinds of transaction 'levels', read > http://www.postgresql.org/docs/8.0/static/transaction-iso.html > for more information. It says 'read committed' is the standard level, > but it might be uncommitted for you, if you can select stuff while > transaction is still in progress. > > But, if there's no TRANSACTION at the beginning, then there's something > wrong within Og. > > Jo > Ok - looks to me like something is broken then. Can anyone confirm the following...( more notes inline ) One thing that I note is that the postgresql log shows all the sql statements from the psql test ending with a ';' but none of the Og statements end with ';' in the postgresql log. I believe the BEGIN TRANSACTION is failing because it is not terminated with a ';'? Turning $DBG=true and logging to file... snippet of scripts log file...let it run for a bit, then CTRL-C'd the script INFO: Og uses the Postgresql store. INFO: Created table 'tbltest'. DEBUG: BEGIN TRANSACTION DEBUG: SELECT nextval('tbltest_oid_seq') DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'BUSY', '[123456789]', '[SE]', '[566]', 1, '[01]', '2007/01/02', '[62]') DEBUG: SELECT nextval('tbltest_oid_seq') DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'SITTONE', '[123456789]', '[SE]', '[569]', 2, '[01]', '2007/01/02', '[48]') DEBUG: SELECT nextval('tbltest_oid_seq') DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:54', 'BUSY', '[123456789]', '[SE]', '[566]', 3, '[01]', '2007/01/02', '[62]') DEBUG: SELECT nextval('tbltest_oid_seq') DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:57', 'BUSY', '[123456789]', '[SE]', '[566]', 4, '[01]', '2007/01/02', '[62]') DEBUG: SELECT nextval('tbltest_oid_seq') .... .... DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:21', 'ANSM_LEFTMSG', '[123456789]', '[X2]', '[CPE]', 2056, '[01]', '2007/01/02', '[22]') DEBUG: SELECT nextval('tbltest_oid_seq') DEBUG: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:23', 'NOANSWER', '[123456789]', '[X2]', '[CPE]', 2057, '[01]', '2007/01/02', '[61]') DEBUG: SELECT nextval('tbltest_oid_seq') ERROR: DB error , [SELECT nextval('tbltest_oid_seq')] ERROR: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/adapter/postgresql.rb:125:in `query_statement' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store/sql.rb:556:in `query' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/adapter/postgresql.rb:156:in `insert' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store/sql.rb:102:in `og_insert' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store.rb:94:in `save' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:22:in `save' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:113:in `with_store' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:21:in `save' tbl.rb:50 tbl.rb:36:in `each_line' tbl.rb:36 /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store.rb:205:in `transaction' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:490:in `transaction' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:113:in `with_store' /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:489:in `transaction' tbl.rb:35 DEBUG: ROLLBACK DEBUG: Og::StoreException: Og::StoreException DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store/sql.rb:595:in `handle_sql_exception' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store/sql.rb:559:in `query' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/adapter/postgresql.rb:156:in `insert' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store/sql.rb:102:in `og_insert' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store.rb:94:in `save' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:22:in `save' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:113:in `with_store' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:21:in `save' DEBUG: tbl.rb:50 DEBUG: tbl.rb:36:in `each_line' DEBUG: tbl.rb:36 DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/store.rb:205:in `transaction' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:490:in `transaction' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:113:in `with_store' DEBUG: /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:489:in `transaction' DEBUG: tbl.rb:35 So according to DBG, we started a transaction, did some inserts, I CTRL-C'd the script, we did a ROLLBACK. Per documentation, I should not have been able to read any of the data prior to the commit,, yet selects show data as it is being entered. Also, after the ROLLBACK, all data is still in the table. postgresql log shows... 2007-06-05 08:27:12 EDT LOG: statement: BEGIN TRANSACTION 2007-06-05 08:27:12 EDT LOG: statement: SELECT nextval('tbltest_oid_seq') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'BUSY', '[9544250950]', '[SE]', '[566]', 1, '[01]', '2007/01/02', '[62]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'SITTONE', '[123456789]', '[SE]', '[569]', 2, '[01]', '2007/01/02', '[48]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:54', 'BUSY', '[123456789]', '[SE]', '[566]', 3, '[01]', '2007/01/02', '[62]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:57', 'BUSY', '[123456789]', '[SE]', '[566]', 4, '[01]', '2007/01/02', '[62]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:57', 'SITTONE', '[123456789]', '[SE]', '[566]', 5, '[01]', '2007/01/02', '[48]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:58', 'BUSY', '[123456789]', '[SF]', '[566]', 6, '[01]', '2007/01/02', '[62]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:58', 'BUSY', '[123456789]', '[SE]', '[566]', 7, '[01]', '2007/01/02', '[62]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:05', 'SITTONE', '[123456789]', '[SF]', '[566]', 8, '[01]', '2007/01/02', '[48]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:06', 'SITTONE', '[123456789]', '[SE]', '[566]', 9, '[01]', '2007/01/02', '[48]') 2007-06-05 08:27:12 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:07', 'SITTONE', '[123456789]', '[SE]', '[566]', 10, '[01]', '2007/01/02', '[48]') ... ... 2007-06-05 08:27:26 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:21', 'ANSM_LEFTMSG', '[123456789]', '[X2]', '[CPE]', 2056, '[01]', '2007/01/02', '[22]') 2007-06-05 08:27:26 EDT LOG: statement: SELECT nextval('tbltest_oid_seq') 2007-06-05 08:27:26 EDT LOG: statement: INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:23', 'NOANSWER', '[123456789]', '[X2]', '[CPE]', 2057, '[01]', '2007/01/02', '[61]') 2007-06-05 08:27:26 EDT LOG: statement: SELECT nextval('tbltest_oid_seq') 2007-06-05 08:27:26 EDT LOG: statement: ROLLBACK If I take the postgresql log output and remove the extraneous log info, and feed it to psql ala psql -U rthompso -f /tmp/test tbl, then selects return empty while it is loading, and the rollback leaves the table empty -- I.E. it works as expected... test file.... BEGIN TRANSACTION; INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'BUSY', '[123456789]', '[SE]', '[566]', 1, '[01]', '2007/01/02', '[62]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:53', 'SITTONE', '[123456789]', '[SE]', '[569]', 2, '[01]', '2007/01/02', '[48]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:54', 'BUSY', '[123456789]', '[SE]', '[566]', 3, '[01]', '2007/01/02', '[62]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:57', 'BUSY', '[123456789]', '[SE]', '[566]', 4, '[01]', '2007/01/02', '[62]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:57', 'SITTONE', '[123456789]', '[SE]', '[566]', 5, '[01]', '2007/01/02', '[48]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:58', 'BUSY', '[123456789]', '[SF]', '[566]', 6, '[01]', '2007/01/02', '[62]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:00:58', 'BUSY', '[123456789]', '[SE]', '[566]', 7, '[01]', '2007/01/02', '[62]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:05', 'SITTONE', '[123456789]', '[SF]', '[566]', 8, '[01]', '2007/01/02', '[48]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:06', 'SITTONE', '[123456789]', '[SE]', '[566]', 9, '[01]', '2007/01/02', '[48]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '08:01:07', 'SITTONE', '[123456789]', '[SE]', '[566]', 10, '[01]', '2007/01/02', '[48]'); ... ... INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:20', 'ANSM_LEFTMSG', '[123456789]', '[X2]', '[CPE]', 2055, '[01]', '2007/01/02', '[22]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:21', 'ANSM_LEFTMSG', '[123456789]', '[X2]', '[CPE]', 2056, '[01]', '2007/01/02', '[22]'); INSERT INTO tbltest ("type", "ts", "result", "telno", "location", "calltype", "oid", "fa", "date", "fn") VALUES ('CALL:TN', '09:00:23', 'NOANSWER', '[123456789]', '[X2]', '[CPE]', 2057, '[01]', '2007/01/02', '[61]'); ROLLBACK; From Reid.Thompson at ateb.com Tue Jun 5 09:13:45 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 09:13:45 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181048901.2613.27.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> Message-ID: <1181049225.2613.29.camel@jhereg> On Tue, 2007-06-05 at 09:08 -0400, Reid Thompson wrote: > On Tue, 2007-06-05 at 08:26 +0300, Jonathan Buch wrote: > > Hi, > > > > > It still appears to be committing on each save -- if all records were in > > > a single transaction, no rows should be present until the final commit > > > -- correct???? > > > > > > yet... > > > > that I don't know, have you watched the sql output? That's the best > > way to make sure everything's alright. `$DBG = true` somewhere above > > Og.start will do. With 32k entries it'll be a little messy, but you > > can redirect your output to a file I guess. :) > > So, the first sql statement (after starting up Og) should be a begin > > transaction. > > > > There's all kinds of transaction 'levels', read > > http://www.postgresql.org/docs/8.0/static/transaction-iso.html > > for more information. It says 'read committed' is the standard level, > > but it might be uncommitted for you, if you can select stuff while > > transaction is still in progress. > > > > But, if there's no TRANSACTION at the beginning, then there's something > > wrong within Og. > > > > Jo > > > Ok - looks to me like something is broken then. Can anyone confirm the > following...( more notes inline ) > > One thing that I note is that the postgresql log shows all the sql > statements from the psql test ending with a > ';' but none of the Og statements end with ';' in the postgresql log. I > believe the BEGIN TRANSACTION is failing because it is not terminated > with a ';'? > Adding a ';' after BEGIN TRANSACTION and ROLLBACK does not fix it. From john at oxyliquit.de Tue Jun 5 11:22:01 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 18:22:01 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181048901.2613.27.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> Message-ID: Hi, > If I take the postgresql log output and remove the extraneous log info, > and feed it to psql ala psql -U rthompso -f /tmp/test tbl, then selects > return empty while it is loading, and the rollback leaves the table > empty -- I.E. it works as expected... That is slightly discomforting... In fact, until now I always relied on that working! O.O; ... Downright disturbing.. I just did a small test and see that you're right, it in fact does not work like expected! irb(main):012:0> begin irb(main):013:1* store.start irb(main):014:1> a = User.new; a.name = 'asdf4'; a.save irb(main):023:0* store.conn.transaction_status => 2 # this means inside a transaction, normal status irb(main):015:1> store.exec "select foo blah" irb(main):016:1> rescue Object irb(main):017:1> end irb(main):019:0* store.conn.transaction_status => 3 # This means idle inside a failed transaction irb(main):021:0* store.rollback irb(main):023:0* store.conn.transaction_status => 0 # this means not in a transaction where conn = store.conn conn.exec "BEGIN" conn.exec %{INSERT INTO oguser ("name") VALUES ('asdf4')} conn.exec "ROLLBACK" This works! I'll have to investigate that further.... Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Tue Jun 5 11:33:54 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 18:33:54 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> Message-ID: Hi, store = $og.store conn = store.conn begin store.start a = User.new; a.name = 'asdf5'; a.save conn.exec %{INSERT INTO oguser ("real_name", "password", "update_time", "email", "name", "access_time", "time_deleted", "revision", "phone", "create_time", "phone2", "customer_oid") VALUES (NULL, NULL, NULL, NULL, 'asdf555', NULL, NULL, NULL, NULL, NULL, NULL, NULL)} rescue Object end store.rollback It turned out, that the a.save did end up in the store, while the second one didn't. What does that tell us? We're FUCKED! I didn't take into account that there are 5 stores to choose from, each having his own connection and own transaction. Yes, disturbing. If you will excuse me, I think I'm gonna cry. ;/ Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From Reid.Thompson at ateb.com Tue Jun 5 12:50:46 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 12:50:46 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> Message-ID: <1181062246.29703.20.camel@jhereg> On Tue, 2007-06-05 at 18:33 +0300, Jonathan Buch wrote: > Hi, > > store = $og.store > conn = store.conn > > begin > store.start > a = User.new; a.name = 'asdf5'; a.save > conn.exec %{INSERT INTO oguser ("real_name", "password", "update_time", > "email", "name", "access_time", "time_deleted", "revision", "phone", > "create_time", "phone2", "customer_oid") VALUES (NULL, NULL, NULL, NULL, > 'asdf555', NULL, NULL, NULL, NULL, NULL, NULL, NULL)} > rescue Object > end > > store.rollback > > It turned out, that the a.save did end up in the store, while > the second one didn't. What does that tell us? We're FUCKED! > > I didn't take into account that there are 5 stores to choose from, > each having his own connection and own transaction. > so the default initialization starts 5 connections to the database? and we're utilizing 'more than one' in our scenario? > Yes, disturbing. If you will excuse me, I think I'm gonna cry. ;/ > > Jo > From Reid.Thompson at ateb.com Tue Jun 5 12:53:26 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 12:53:26 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181062246.29703.20.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> Message-ID: <1181062406.29703.22.camel@jhereg> On Tue, 2007-06-05 at 12:50 -0400, Reid Thompson wrote: > On Tue, 2007-06-05 at 18:33 +0300, Jonathan Buch wrote: > > Hi, > > > > store = $og.store > > conn = store.conn > > > > begin > > store.start > > a = User.new; a.name = 'asdf5'; a.save > > conn.exec %{INSERT INTO oguser ("real_name", "password", "update_time", > > "email", "name", "access_time", "time_deleted", "revision", "phone", > > "create_time", "phone2", "customer_oid") VALUES (NULL, NULL, NULL, NULL, > > 'asdf555', NULL, NULL, NULL, NULL, NULL, NULL, NULL)} > > rescue Object > > end > > > > store.rollback > > > > It turned out, that the a.save did end up in the store, while > > the second one didn't. What does that tell us? We're FUCKED! > > > > I didn't take into account that there are 5 stores to choose from, > > each having his own connection and own transaction. > > > > so the default initialization starts 5 connections to the database? > and we're utilizing 'more than one' in our scenario? OK -- I think I see... ./lib/og/manager.rb 66: (options[:connection_count] || 5).times do > > > Yes, disturbing. If you will excuse me, I think I'm gonna cry. ;/ > > > > Jo > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From Reid.Thompson at ateb.com Tue Jun 5 13:09:57 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 13:09:57 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181062406.29703.22.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> Message-ID: <1181063397.29703.27.camel@jhereg> On Tue, 2007-06-05 at 12:53 -0400, Reid Thompson wrote: > > > > > > > so the default initialization starts 5 connections to the database? > > and we're utilizing 'more than one' in our scenario? > > OK -- I think I see... > ./lib/og/manager.rb > 66: (options[:connection_count] || 5).times do explicitly setting :connection_count => doesn't yield what I expected either.... had thought that setting only one connection would force all transactions through that 1 and only connection... From george.moschovitis at gmail.com Tue Jun 5 14:00:58 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 5 Jun 2007 21:00:58 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181063397.29703.27.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> Message-ID: Argh... this is very annoying indeed... unless anyone beats me and provides a patch (hint, hint) I will resolve this tomorrow. -g. On 6/5/07, Reid Thompson wrote: > > On Tue, 2007-06-05 at 12:53 -0400, Reid Thompson wrote: > > > > > > > > > > > so the default initialization starts 5 connections to the database? > > > and we're utilizing 'more than one' in our scenario? > > > > OK -- I think I see... > > ./lib/og/manager.rb > > 66: (options[:connection_count] || 5).times do > > explicitly setting :connection_count => doesn't yield what I expected > either.... had thought that setting only one connection would force all > transactions through that 1 and only connection... > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://georgeandstella.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/20070605/0293c702/attachment.html From john at oxyliquit.de Tue Jun 5 14:21:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 21:21:28 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181063397.29703.27.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> Message-ID: Hi, > explicitly setting :connection_count => doesn't yield what I expected > either.... had thought that setting only one connection would force all > transactions through that 1 and only connection... in fact (in theory anyway) using a transaction while having :c_count on 1 would block the whole Thread (and so all Nitro/etc). This is because the transaction gets one store from the pool, and when the User.create wants its pool, it will block because there's no more stores in the pool, waiting for stores to appear. But, one iteration before this Manager, the manager leaked stores, just creating new stores when there were no more stores in the pool, great fun... I haven't looked in that area for quite some time now, maybe I should do that more often... So, this still could be happening, if the transaction/.create does not block, there's something seriously wrong (nice for test case btw). So, we need somehow a way to a) specify the store when using .save or alternatively b) (using some very clever method I can't think of) use the same store from transaction for database interactions within a transaction. idea: def transaction oldcrit = Thread.critical Thread.critical = true start Thread.current[:transaction_store] = self yield self rescue Object => ex rollback Logger.debug "#{ex.class}: #{ex.message}" ex.backtrace.each {|line| Logger.debug line} Thread.current[:transaction_store] = nil Thread.critical = oldcrit else commit Thread.current[:transaction_store] = nil Thread.critical = oldcrit end So, creating a critical section, and saving the store. This store could then be used within store-consuming methods (like in the manager handing out stores would always first try to get from Thread.current[:transaction_store] instead of the pool. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Tue Jun 5 14:37:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 21:37:28 +0300 Subject: [Nitro] George: First Class Swiftiply Support? Message-ID: Hi, this is just a reminder, please decide on this matter. :) [21:22] swiftiply is easy. The Mongrel support already exists. The only real issue is that when one uses Nitro's builtin support for spawning multiple processes, it's behavior needs to change slightly when using it with Swiftiply. It has to spawn them all against the same port, instead of different port numbers. [21:24] I can write the patches. No big deal. But do you want me to give them to you, to include it directly in Nitro, or do you want it to be an add-on. A swiftiply_nitro executable that requires the patches? [21:25] wyhaines, this is defined in nitro/bin/nitro [21:25] http://pastie.caboo.se/68011 [21:25] exec_application(f, i + 1) here (second argument) increments the port [21:26] so, this being a bin which gets installed... I dunno how that can be 'patched' [21:27] argh... this uses kill -9 in there [21:28] I'd include a swiftiply_nitro executable. It'd basically just load the regular nitro executable, then require the patch. [21:29] that sounds ok :) [21:29] thank you for caring enough about Nitro to do this ^_^ [21:30] But it'd be nicer if there could just be a flag or an environment variable aware bit of code right in Nitro that gives it first class swiftiply support. I just need George to let me know which way he wants it to go. So, basically we could create a `if $SWIFTIPLY` and require the swiftiplied mongrel version from swiftiply and on the same we could disable the port incrementing I mentioned there above. This would be the 'first class support', second class would be Haines creating his own binary for us and installing that when one installs swiftiply. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From Reid.Thompson at ateb.com Tue Jun 5 15:30:08 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 15:30:08 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> Message-ID: <1181071808.29703.36.camel@jhereg> On Tue, 2007-06-05 at 21:21 +0300, Jonathan Buch wrote: > Hi, > > > explicitly setting :connection_count => doesn't yield what I expected > > either.... had thought that setting only one connection would force all > > transactions through that 1 and only connection... > > in fact (in theory anyway) using a transaction while having :c_count on > 1 would block the whole Thread (and so all Nitro/etc). This is because > the transaction gets one store from the pool, and when the User.create > wants its pool, it will block because there's no more stores in the > pool, waiting for stores to appear. It does, at least I assume that's what the below error means.... rthompso at jhereg:~$ ruby tbl4.rb INFO: Og uses the Postgresql store. DEBUG: Og manageable classes: [Loadtbl] DEBUG: CREATE TABLE tbl4test ("date" text, "ts" text, "type" text, "telno" text, "location" text, "calltype" text, "fa" text, "fn" text, "result" text, "oid" serial PRIMARY KEY) WITHOUT OIDS INFO: Created table 'tbl4test'. DEBUG: SELECT * FROM tbl4test LIMIT 1 DEBUG: SELECT * FROM tbl4test LIMIT 1 /usr/lib/ruby/1.8/monitor.rb:102:in `stop': stopping only thread (ThreadError) note: use sleep to stop forever from /usr/lib/ruby/1.8/monitor.rb:102:in `wait' from /usr/lib/ruby/1.8/monitor.rb:123:in `wait_while' from /usr/lib/ruby/gems/1.8/gems/facets-1.8.54/lib/facets/more/pool.rb:56:in `pop' from /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' from /usr/lib/ruby/gems/1.8/gems/facets-1.8.54/lib/facets/more/pool.rb:55:in `pop' from /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:94:in `get_store' from /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/manager.rb:112:in `with_store' from /home/rthompso/src/repo.nitroproject.org/script/../og/lib/og/model.rb:489:in `transaction' from tbl4.rb:36 From john at oxyliquit.de Tue Jun 5 15:34:35 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 22:34:35 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181071808.29703.36.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> Message-ID: Hi, >> wants its pool, it will block because there's no more stores in the >> pool, waiting for stores to appear. > > It does, at least I assume that's what the below error means.... > /usr/lib/ruby/1.8/monitor.rb:102:in `stop': stopping only thread that I actually regard as a good sign. :P G promised to work on this *glare* so I very much hope that this can be gotten over with without me changing too much in my current project which is kinda huge-ish... (and the first in which I really needed transactions..) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From Reid.Thompson at ateb.com Tue Jun 5 15:45:50 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Tue, 05 Jun 2007 15:45:50 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> Message-ID: <1181072750.29703.44.camel@jhereg> On Tue, 2007-06-05 at 22:34 +0300, Jonathan Buch wrote: > Hi, > > >> wants its pool, it will block because there's no more stores in the > >> pool, waiting for stores to appear. > > > > It does, at least I assume that's what the below error means.... > > > /usr/lib/ruby/1.8/monitor.rb:102:in `stop': stopping only thread > > that I actually regard as a good sign. :P > > G promised to work on this *glare* so I very much hope that this can > be gotten over with without me changing too much in my current project > which is kinda huge-ish... (and the first in which I really needed > transactions..) > > Jo > So... my timing was perfect From john at oxyliquit.de Tue Jun 5 15:56:50 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 05 Jun 2007 22:56:50 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181072750.29703.44.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: Hi, > So... my timing was perfect yes it was, and I thank you very much for that. :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From dan at tastapod.com Tue Jun 5 18:56:58 2007 From: dan at tastapod.com (Dan North) Date: Tue, 05 Jun 2007 23:56:58 +0100 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> Message-ID: <4665EA3A.1060605@tastapod.com> You could steal a Java trick and associate a connection with the current thread when you begin a transaction. Then each call to $og.store.conn checks to see whether the current thread is in a transaction, and if so which connection is servicing it (basically a hash lookup of thread.__id__ to connection, defaulting to anything-from-the-pool). When the connection is committed or rolled back, the association is broken so any further calls to $og.store.conn go back to the pool again. But then I'm coming in halfway through this, so I might be way off :) Cheers, Dan George Moschovitis wrote: > Argh... this is very annoying indeed... > > unless anyone beats me and provides a patch (hint, hint) I will > resolve this tomorrow. > > -g. > > On 6/5/07, * Reid Thompson* > wrote: > > On Tue, 2007-06-05 at 12:53 -0400, Reid Thompson wrote: > > > > > > > > > > > so the default initialization starts 5 connections to the > database? > > > and we're utilizing 'more than one' in our scenario? > > > > OK -- I think I see... > > ./lib/og/manager.rb > > 66: (options[:connection_count] || 5).times do > > explicitly setting :connection_count => doesn't yield what I expected > either.... had thought that setting only one connection would > force all > transactions through that 1 and only connection... > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > > > > -- > http://georgeandstella.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070605/ca533664/attachment-0001.html From john at oxyliquit.de Wed Jun 6 02:05:16 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 06 Jun 2007 09:05:16 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <4665EA3A.1060605@tastapod.com> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <4665EA3A.1060605@tastapod.com> Message-ID: Hi, > You could steal a Java trick and associate a connection with the current > thread when you begin a transaction. Then each call to $og.store.conn > checks to see whether the current thread is in a transaction, and if so > which connection is servicing it (basically a hash lookup of > thread.__id__ to connection, defaulting to anything-from-the-pool). > > When the connection is committed or rolled back, the association is > broken so any further calls to $og.store.conn go back to the pool again. this is exactly the idea which I had and already posted, good, that means we're on the right track if others are doing that successfully already! > But then I'm coming in halfway through this, so I might be way off :) Nope, you're helping, really good to see that this approach works. :P Would be good to know if there are any race conditions though and if my Thread.critical was necessary there... Anyway, thank you very much, Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Wed Jun 6 02:35:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 06 Jun 2007 09:35:28 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181072750.29703.44.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: Hi, this apparently fixes the transaction (for postgresql only), please report back. Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -------------- next part -------------- A non-text attachment was scrubbed... Name: transact.bndl Type: application/octet-stream Size: 40385 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070606/cf627c48/attachment-0001.obj From george.moschovitis at gmail.com Wed Jun 6 02:53:18 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 6 Jun 2007 09:53:18 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: thanks! -g. On 6/6/07, Jonathan Buch wrote: > > Hi, > > this apparently fixes the transaction (for postgresql only), > please report back. > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- http://georgeandstella.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/20070606/c34f6519/attachment.html From john at oxyliquit.de Wed Jun 6 09:59:20 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 06 Jun 2007 16:59:20 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: Hi, > thanks! yeh, and I think I know why that didn't really bite anyone else. The implementation before did some tricks with Thread[] as well, so the same thread always got the current store. Now, George, could still make that promised 'Og day' this week even with this resolved? /me reminds of the test cases and maybe a mysql/ sqlite translation of the transaction stuff. Thank you very much! Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Wed Jun 6 10:11:38 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 6 Jun 2007 17:11:38 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: > > and maybe a mysql/ > sqlite translation of the transaction stuff. > I just did the translation, will push to the repo ASAP. -g. -- 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/20070606/7c602bc6/attachment.html From Reid.Thompson at ateb.com Fri Jun 8 10:24:56 2007 From: Reid.Thompson at ateb.com (Reid Thompson) Date: Fri, 08 Jun 2007 10:24:56 -0400 Subject: [Nitro] Request for Transaction example In-Reply-To: References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> Message-ID: <1181312696.13965.10.camel@jhereg> On Wed, 2007-06-06 at 09:35 +0300, Jonathan Buch wrote: > Hi, > > this apparently fixes the transaction (for postgresql only), > please report back. > > Jo > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ Sorry for the late reply -- got pulled off on something else. This does now appear to be working correctly for me. Inserts/saves are not visible until end of transaction/committed and 'ing to force a rollback leaves no data in the table. Thanks, reid From john at oxyliquit.de Fri Jun 8 11:06:48 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 08 Jun 2007 18:06:48 +0300 Subject: [Nitro] Request for Transaction example In-Reply-To: <1181312696.13965.10.camel@jhereg> References: <1180983120.20824.15.camel@jhereg> <1180989297.32064.4.camel@jhereg> <1181048901.2613.27.camel@jhereg> <1181062246.29703.20.camel@jhereg> <1181062406.29703.22.camel@jhereg> <1181063397.29703.27.camel@jhereg> <1181071808.29703.36.camel@jhereg> <1181072750.29703.44.camel@jhereg> <1181312696.13965.10.camel@jhereg> Message-ID: Hi, >> this apparently fixes the transaction (for postgresql only), >> please report back. > Sorry for the late reply -- got pulled off on something else. > This does now appear to be working correctly for me. Inserts/saves are > not visible until end of transaction/committed and 'ing to force > a rollback leaves no data in the table. > > Thanks you're welcome, glad to be of help. :) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From arne at arnebrasseur.net Sat Jun 9 11:22:39 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sat, 09 Jun 2007 17:22:39 +0200 Subject: [Nitro] scaffold and helper dropped? Message-ID: <466AC5BF.3060403@arnebrasseur.net> Hi, It appears a number of things have been dropped between 0.4.2 and repo (to become 0.5.0). Things I've noticed (unless I've overseen) are the helper method for Controller, and the scaffold/scaffolding code. Are they planned to return or not? Just curious. regards (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From john at oxyliquit.de Sat Jun 9 11:50:39 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 09 Jun 2007 18:50:39 +0300 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: <466AC5BF.3060403@arnebrasseur.net> References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: HI, > It appears a number of things have been dropped between 0.4.2 and repo > (to become 0.5.0). > > Things I've noticed (unless I've overseen) are the helper method for > Controller, and the scaffold/scaffolding code. > > Are they planned to return or not? Just curious. not sure about scaffolding, but helper has been dropped by George for sure. He wants to use less 'non standard' tags. I happen to like the helper method though, but that's just me. :P (I never used scaffolding, so can't say anything about that.) Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Jun 9 13:10:01 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 9 Jun 2007 20:10:01 +0300 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: please use include PagerHelper include Karma include SEOname etc, instead of helper :pager helper :karma helper :seoname likewise the new version uses standard modules for scaffolding. class MyModel include Enchant end there is an option that automatically enchants all models. or for controller level scaffolding: class MyModel::Controller include REST end adds some standard REST methods. I think I have not commited rest.rb to the repo, will do soon. regards, George On 6/9/07, Jonathan Buch wrote: > > HI, > > > It appears a number of things have been dropped between 0.4.2 and repo > > (to become 0.5.0). > > > > Things I've noticed (unless I've overseen) are the helper method for > > Controller, and the scaffold/scaffolding code. > > > > Are they planned to return or not? Just curious. > > not sure about scaffolding, but helper has been dropped by George for > sure. He wants to use less 'non standard' tags. I happen to like the > helper method though, but that's just me. :P > (I never used scaffolding, so can't say anything about that.) > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- 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/20070609/9de267d8/attachment.html From john at oxyliquit.de Sat Jun 9 14:13:50 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 09 Jun 2007 21:13:50 +0300 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: Hi, you have used a slightly 'wrong' comparison: :P > include PagerHelper > include KarmaHelper > include SeonameHelper > etc, instead of helper :pager, :karma, :seoname Which means, it's a very clean non-disturbing way to specify standard named modules which fit one a single line. :P But I'm not really arguing here, don't mind me. :P Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Jun 9 16:02:04 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 9 Jun 2007 23:02:04 +0300 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: On 6/9/07, Jonathan Buch wrote: > > Hi, > > you have used a slightly 'wrong' comparison: :P > > > include PagerHelper > > include KarmaHelper > > include SeonameHelper > > > etc, instead of > > helper :pager, :karma, :seoname no... I meant include PagerHelper, Karma, SEOname I dont use the Helper prefix in my modules... (just in the PagerHelper module) so it looks exactly the same and is standard ruby... -g. Which means, it's a very clean non-disturbing way to specify > standard named modules which fit one a single line. :P > > But I'm not really arguing here, don't mind me. :P > > Jo > > -- > Feel the love > http://pinkjuice.com/pics/ruby.png > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- 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/20070609/f2762504/attachment-0001.html From george.moschovitis at gmail.com Sat Jun 9 16:02:28 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 9 Jun 2007 23:02:28 +0300 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: > > I dont use the Helper prefix in my modules... (just in the PagerHelper > module) > make that postfix ;-) -g. -- 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/20070609/a822dca4/attachment.html From arne at arnebrasseur.net Sun Jun 10 03:43:43 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 10 Jun 2007 09:43:43 +0200 Subject: [Nitro] scaffold and helper dropped? In-Reply-To: References: <466AC5BF.3060403@arnebrasseur.net> Message-ID: <466BABAF.5070904@arnebrasseur.net> George Moschovitis schreef: > please use > > include PagerHelper > include Karma > include SEOname > > etc, instead of > > helper :pager > helper :karma > helper :seoname Ok, that's what I needed to know. > class MyModel::Controller > include REST > end > > adds some standard REST methods. Cool > I think I have not commited rest.rb to the repo, will do soon. Please do, I was about to write something like that myself. (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From rob at robmela.com Mon Jun 11 08:16:03 2007 From: rob at robmela.com (Robert Mela) Date: Mon, 11 Jun 2007 08:16:03 -0400 Subject: [Nitro] Nitro/Rails interoperability In-Reply-To: <466BABAF.5070904@arnebrasseur.net> References: <466AC5BF.3060403@arnebrasseur.net> <466BABAF.5070904@arnebrasseur.net> Message-ID: <466D3D03.8070302@robmela.com> It's occurred to me that Nitro could have a role as release valve for overworked Nitro applications. I'm considering taking on an assignment where that's one of the first options I'd try -- offloading a very simple but time consuming piece from Rails onto a separate Nitro server. Jonathan answered the first of my questions in that area by showing me how Og can be used with legacy tables. Other pieces I imagine would be some adapters that let Nitro read and write to Rails' session and request objects, and generate URIs that work well with Rails back-ends. I think most people would see it as a low-risk experiment to offload certain simple tasks from Rails to Nitro. In the context of a situation where scalability issues are a significant time drain, there is strong incentive for applying a Nitro solution. Rails folk are already talking about Scala and Lift. Nitro offers the advantage of leveraging existing Ruby skills and infrastructure. Example: Assume a Typo blog with growing traffic requiring multiple Typo processes. Nitro could be used to read Typo's schema and display most pages. This is considerably easier to do than reimplementing *all* of the Typo functionality. Since blog administration is low traffic, a single Typo process could handle all the admin, and all or most of the remaining typo processes could be replaced by a single Nitro process. There are other cases where the offloaded tasks are even simpler -- e.g., a page that gathers a number of resources from elsewhere (e.g., retrieving several dozen images from a database ). Rails could continue to generate the overall page, but pass image retrieval URLs to a Nitro server Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: rob.vcf Type: text/x-vcard Size: 116 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070611/59dcef33/attachment.vcf From john at oxyliquit.de Tue Jun 12 11:46:26 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Tue, 12 Jun 2007 18:46:26 +0300 Subject: [Nitro] Newbie Impressions Message-ID: Hi, [18:10] Is there some kind of "getting started" guide for nitro [18:10] the documentation seems to be very sparse [18:11] yes, docs are sparse and often outdated, which is sad ;/ [18:11] have you seen http://oxyliquit.de/ ? [18:11] are you just suppoed to "Know" [18:11] Yeah [18:11] But it doesnt help me [18:11] where do I start ? [18:11] ok, have you seen the screencasts? [18:11] Yeah... [18:11] But it still doesnt explain anything [18:11] its just a guy recording himself typing [18:12] well, it's "just like that" [18:12] look at Nitro how you look at ruby [18:12] I know... :( [18:12] Im a ruby noob too [18:35] Do you have any idea when the new nitro site is gonna be done [18:35] allright, so, now, do you get to see the /input page? [18:36] new nitro site? I haven't heard anything about that [18:36] No I mean when is he gonna finish the current one [18:37] everything on it is a dummy link Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Tue Jun 12 17:01:36 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Wed, 13 Jun 2007 00:01:36 +0300 Subject: [Nitro] Nitro/Rails interoperability In-Reply-To: <466D3D03.8070302@robmela.com> References: <466AC5BF.3060403@arnebrasseur.net> <466BABAF.5070904@arnebrasseur.net> <466D3D03.8070302@robmela.com> Message-ID: Hi, will get back to you on this one, need more time to think. From arne at arnebrasseur.net Tue Jun 12 17:14:33 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 12 Jun 2007 23:14:33 +0200 Subject: [Nitro] Part.require Message-ID: <466F0CB9.40900@arnebrasseur.net> Hi, I was looking at nitro/part.rb. The rdoc says that part/name/run.rb is an optional standalone example app. This make sense to me. Later on there is a method Part.require that requires that run.rb. Is this the intended behaviour? Should it be used within a Nitro app or not? Personally I'd say it would make more sense to let Part.require 'users' issue require 'part/users' It's a trivial change but I could send a patch if you prefer. regards (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From arne at arnebrasseur.net Tue Jun 12 17:31:09 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Tue, 12 Jun 2007 23:31:09 +0200 Subject: [Nitro] Newbie Impressions In-Reply-To: References: Message-ID: <466F109D.60601@arnebrasseur.net> Jonathan Buch schreef: > Hi, > > [18:10] Is there some kind of "getting started" guide for nitro > [18:10] the documentation seems to be very sparse > [18:11] yes, docs are sparse and often outdated, which is sad > ;/ > [18:11] have you seen http://oxyliquit.de/ ? > [18:11] are you just suppoed to "Know" > This is definitely a sore point for Nitro. I would like to help to create some sort of manual by the time 0.5.0 is released (which probably won't be tomorrow anyway). I'm still quite new to Nitro but I try to regularly read some source and try to make some notes as I go along. Jo and I talked about it a bit on IRC and he pointed out the Django docs (http://www.djangoproject.com/documentation/). We could follow a similar structure with a step-by-step guide for newbies followed by a complete reference section. I'm thinking a wiki-like system for the editors, but freeze the text when it is released after which only comments can be made (like with postgresql/php docs). Ideally each section would contain it's own unit tests to see if the examples are still valid with new versions, altough I think at this point it is more important to focus on actually getting some docs together. Other opinions on this? Any source diggers willing to contribute? thank you (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From mattrose at folkwolf.net Tue Jun 12 17:35:03 2007 From: mattrose at folkwolf.net (Matt Rose) Date: Tue, 12 Jun 2007 17:35:03 -0400 Subject: [Nitro] Newbie Impressions In-Reply-To: <466F109D.60601@arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> Message-ID: <68F513E3-1706-4DE7-9022-B6E26D8B2845@folkwolf.net> I'd be in on that. I've done some diving in the code, but I've actually pretty much given up on nitro because of the lack of documentation, so I'm a little rusty. Matt On 12-Jun-07, at 5:31 PM, Arne Brasseur wrote: > Jonathan Buch schreef: >> Hi, >> >> [18:10] Is there some kind of "getting started" guide for >> nitro >> [18:10] the documentation seems to be very sparse >> [18:11] yes, docs are sparse and often outdated, which >> is sad >> ;/ >> [18:11] have you seen http://oxyliquit.de/ ? >> [18:11] are you just suppoed to "Know" >> > This is definitely a sore point for Nitro. I would like to help to > create some sort of manual by the time 0.5.0 is released (which > probably > won't be tomorrow anyway). I'm still quite new to Nitro but I try to > regularly read some source and try to make some notes as I go along. > > Jo and I talked about it a bit on IRC and he pointed out the Django > docs > (http://www.djangoproject.com/documentation/). We could follow a > similar > structure with a step-by-step guide for newbies followed by a complete > reference section. I'm thinking a wiki-like system for the editors, > but > freeze the text when it is released after which only comments can be > made (like with postgresql/php docs). > > Ideally each section would contain it's own unit tests to see if the > examples are still valid with new versions, altough I think at this > point it is more important to focus on actually getting some docs > together. > > Other opinions on this? Any source diggers willing to contribute? > > > thank you > (ab) > > -- > Arne Brasseur @ your service > http://www.arnebrasseur.net > arne at arnebrasseur.net > +32/496/94.55.63 > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From transfire at gmail.com Tue Jun 12 20:16:08 2007 From: transfire at gmail.com (TRANS) Date: Tue, 12 Jun 2007 20:16:08 -0400 Subject: [Nitro] Helping to polish the nitroproject web page Message-ID: <4b6f054f0706121716u55adf6bdjbd1b9f0b29764c74@mail.gmail.com> I resized the image to fit the small box above the "what's new" image on the nitroproject.org web page. Could we get it added with a link. Thanks, T. -- o trans. Never face facts; if you do, you'll never get up in the ^^ transfire at gmail.com morning. - Marlo Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: oxy2.png Type: image/png Size: 27369 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070612/7cc7602b/attachment-0001.png From william.full.moon at gmail.com Wed Jun 13 01:41:31 2007 From: william.full.moon at gmail.com (* William) Date: Wed, 13 Jun 2007 15:41:31 +1000 Subject: [Nitro] Newbie Impressions In-Reply-To: <466F109D.60601@arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> Message-ID: <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> Hey that's cool. Everytime something for "start here" gets done, the product upgrades and things become out of place. Or we loose the wiki and can't update material to keep "close to -works-as-coded- descriptions" :-D I like the proposal -- there are sites like this that provide on-line document management, etc. There needs to be a documentation review process with checks and balances, and stable location/support -- *At least* for starter material. I responded mostly because the key here is that for a fancy product like NITRO, the "get started" body of work should be very simple. There are old articles on getting a start with Ruby on Rails about. The most 'famous' is probably the one on O'Reily -- it has only been updated once, in a big way. I feel that people get too excited by the cool stuff and forget about the new person who know nothing. That person only needs the basics -- Just like Georges video -- What has happened to the replacement video?? It is all good work -- please continue. For something really cool what about a Nitro 3-D plastic models module ... See here: * http://www.marksman.com.au/ The coolest thing so far (apart from Nitro). ... Will. On 13/06/07, Arne Brasseur wrote: > > Jonathan Buch schreef: > > Hi, > > > > [18:10] Is there some kind of "getting started" guide for nitro > > [18:10] the documentation seems to be very sparse > > [18:11] yes, docs are sparse and often outdated, which is > sad > > ;/ > > [18:11] have you seen http://oxyliquit.de/ ? > > [18:11] are you just suppoed to "Know" > > > This is definitely a sore point for Nitro. I would like to help to > create some sort of manual by the time 0.5.0 is released (which probably > won't be tomorrow anyway). I'm still quite new to Nitro but I try to > regularly read some source and try to make some notes as I go along. > > Jo and I talked about it a bit on IRC and he pointed out the Django docs > (http://www.djangoproject.com/documentation/). We could follow a similar > structure with a step-by-step guide for newbies followed by a complete > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070613/da757a70/attachment.html From george.moschovitis at gmail.com Wed Jun 13 03:39:42 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 13 Jun 2007 10:39:42 +0300 Subject: [Nitro] Part.require In-Reply-To: <466F0CB9.40900@arnebrasseur.net> References: <466F0CB9.40900@arnebrasseur.net> Message-ID: You are right, please send me the patch. -g. On 6/13/07, Arne Brasseur wrote: > > Hi, > > I was looking at nitro/part.rb. The rdoc says that part/name/run.rb is > an optional standalone example app. This make sense to me. Later on > there is a method Part.require that requires that run.rb. Is this the > intended behaviour? Should it be used within a Nitro app or not? > > Personally I'd say it would make more sense to let > Part.require 'users' > issue > require 'part/users' > > It's a trivial change but I could send a patch if you prefer. > > regards > (ab) > > > -- > Arne Brasseur @ your service > http://www.arnebrasseur.net > arne at arnebrasseur.net > +32/496/94.55.63 > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- 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/20070613/a5af4f99/attachment.html From arne at arnebrasseur.net Wed Jun 13 04:07:17 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Wed, 13 Jun 2007 01:07:17 -0700 (PDT) Subject: [Nitro] Newbie Impressions In-Reply-To: <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> Message-ID: <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> > Hey that's cool. > > Everytime something for "start here" gets done, the product upgrades and > things become out of place. Or we loose the wiki and can't update > material > to keep "close to -works-as-coded- descriptions" :-D This seems to be a problem. Many Nitro links found across the web no longer work. I heard someone was going to set up a 'reaally cool site' for documentation stuff, but then vanished. Apparently (if I'm not mistaken) there used to be a Nitro wiki, wich I personally think would be fantastic. Oxywtf is great to have, but there's something organic about wikis that just can't be found elsewhere. > I like the proposal -- there are sites like this that provide on-line > document management, etc. Do you know of any? Pointers please! > There needs to be a documentation review process agreed, preferably by developer(s) (hint) > a Nitro 3-D plastic models module ... I don't see how this is related. So as not to reinvent the wheel I've been looking at how others organize their docs. Django, PHP and PostgreSQL all use version controlled plain text files. Django uses the ReST (Restructured Text) format, PHP and postgres use DocBook. Any other FOSS projects with superb docs that should be included in the comparison? (ab) From george.moschovitis at gmail.com Wed Jun 13 04:13:52 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 13 Jun 2007 11:13:52 +0300 Subject: [Nitro] Newbie Impressions In-Reply-To: <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> Message-ID: > > there used to be a Nitro wiki, wich I personally think would be fantastic. > Oxywtf is great to have, but there's something organic about wikis that > just can't be found elsewhere. > I will bring back the wiki. I am not sure though, should I make the wiki writeable by everyone? or give write access only to selected members of the community. Moreover, we would need some guidelines, ie how to organize this wiki. Can anyone in this ml suggest a good set of guidelines? -g. -- 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/20070613/4fe3d5b7/attachment.html From arne at arnebrasseur.net Wed Jun 13 04:20:00 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Wed, 13 Jun 2007 01:20:00 -0700 (PDT) Subject: [Nitro] Part.require In-Reply-To: References: <466F0CB9.40900@arnebrasseur.net> Message-ID: <2969.81.246.186.164.1181722800.squirrel@webmail.arnebrasseur.net> I hope I've done this right (ab) > You are right, please send me the patch. > > -g. > > On 6/13/07, Arne Brasseur wrote: >> >> Hi, >> >> I was looking at nitro/part.rb. The rdoc says that part/name/run.rb is >> an optional standalone example app. This make sense to me. Later on >> there is a method Part.require that requires that run.rb. Is this the >> intended behaviour? Should it be used within a Nitro app or not? >> >> Personally I'd say it would make more sense to let >> Part.require 'users' >> issue >> require 'part/users' >> >> It's a trivial change but I could send a patch if you prefer. >> >> regards >> (ab) >> >> >> -- >> Arne Brasseur @ your service >> http://www.arnebrasseur.net >> arne at arnebrasseur.net >> +32/496/94.55.63 >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general >> > > > > -- > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_part_require.patch.tar.gz Type: application/gzip Size: 12336 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070613/57dcb7d2/attachment-0001.bin From arne at arnebrasseur.net Wed Jun 13 04:48:25 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Wed, 13 Jun 2007 01:48:25 -0700 (PDT) Subject: [Nitro] Newbie Impressions In-Reply-To: References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> Message-ID: <2982.81.246.186.164.1181724505.squirrel@webmail.arnebrasseur.net> > > I will bring back the wiki. I am not sure though, should I make the wiki > writeable by everyone? or give write access only to selected members of > the > community. My very personal opion is that a wiki should be public, but make sure you have decent spam protection. A wiki is a real community tool, and especially great for cookbook style recipes, tutorials, howtos. For real docs/manuals (again IMHO) a more structured and controlled approach would be better, but we could start out on the wiki. A good thing with text files+markup is that they are output agnostic. You can bundle them with the source, generate a web site, a pdf, a CHM (windows help file), etc. (ab) From eeklund at gmail.com Wed Jun 13 05:34:24 2007 From: eeklund at gmail.com (Eivind Eklund) Date: Wed, 13 Jun 2007 11:34:24 +0200 Subject: [Nitro] Newbie Impressions In-Reply-To: <466F109D.60601@arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> Message-ID: On 6/12/07, Arne Brasseur wrote: > Ideally each section would contain it's own unit tests to see if the > examples are still valid with new versions, altough I think at this > point it is more important to focus on actually getting some docs together. Hearing that there have been docs that are now outdated/removed, it seems like unit tests to keep the docs working might be more important than the actual docs. It would at least be a very large plus, as it force the docs to keep working... Eivind. From arne at arnebrasseur.net Wed Jun 13 06:16:52 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Wed, 13 Jun 2007 03:16:52 -0700 (PDT) Subject: [Nitro] Newbie Impressions In-Reply-To: References: <466F109D.60601@arnebrasseur.net> Message-ID: <3100.81.246.186.164.1181729812.squirrel@webmail.arnebrasseur.net> > Hearing that there have been docs that are now outdated/removed, it > seems like unit tests to keep the docs working might be more important > than the actual docs. It would at least be a very large plus, as it > force the docs to keep working... You may be right, I don't have much experience with unit-testing web stuff, but I'll look at the existing tests to get some inspiration. I'm starting to see some duplicate effort here. The docs would partially overlap with the rDoc, and included tests/specs would overlap with the tests already in Nitro. Since converting tests to specs is on the to-do list perhaps this could be looked at together with documenting stuff. Tests are after all a form of executable documentation. I think we need some more brainstorming on how -formal docs, possibly with tests -rDoc -tests/specs should relate to each other. I believe all three have their place, but some coordination would be required. For example: first write rSpec and contribute, then write doc and refer to the spec with filename and revision number. Other thoughts? (ab) From george.moschovitis at gmail.com Thu Jun 14 05:31:35 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 14 Jun 2007 12:31:35 +0300 Subject: [Nitro] Part.require In-Reply-To: <2969.81.246.186.164.1181722800.squirrel@webmail.arnebrasseur.net> References: <466F0CB9.40900@arnebrasseur.net> <2969.81.246.186.164.1181722800.squirrel@webmail.arnebrasseur.net> Message-ID: applied. On 6/13/07, arne at arnebrasseur.net wrote: > > I hope I've done this right > > (ab) > > > You are right, please send me the patch. > > > > -g. > > > > On 6/13/07, Arne Brasseur wrote: > >> > >> Hi, > >> > >> I was looking at nitro/part.rb. The rdoc says that part/name/run.rb is > >> an optional standalone example app. This make sense to me. Later on > >> there is a method Part.require that requires that run.rb. Is this the > >> intended behaviour? Should it be used within a Nitro app or not? > >> > >> Personally I'd say it would make more sense to let > >> Part.require 'users' > >> issue > >> require 'part/users' > >> > >> It's a trivial change but I could send a patch if you prefer. > >> > >> regards > >> (ab) > >> > >> > >> -- > >> Arne Brasseur @ your service > >> http://www.arnebrasseur.net > >> arne at arnebrasseur.net > >> +32/496/94.55.63 > >> _______________________________________________ > >> Nitro-general mailing list > >> Nitro-general at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/nitro-general > >> > > > > > > > > -- > > http://phidz.com > > http://blog.gmosx.com > > http://cull.gr > > http://www.joy.gr > > http://nitroproject.org > > _______________________________________________ > > Nitro-general mailing list > > Nitro-general at rubyforge.org > > http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- 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/20070614/e2c9af18/attachment.html From dan at tastapod.com Thu Jun 14 18:06:15 2007 From: dan at tastapod.com (Dan North) Date: Thu, 14 Jun 2007 23:06:15 +0100 Subject: [Nitro] Newbie Impressions In-Reply-To: References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> Message-ID: <4671BBD7.2070307@tastapod.com> Hi George. I would suggest keeping the wiki public, and then think about locking it down if it gets abused (which is unlikely). DHH did a very smart thing in the run-up to Rails 1.0, which was that he committed to "not break the book". In other words, the RoR book - which was published to coincide with the 1.0 release - would be the reference point and the development team would not break compatibility with anything in it. After 1.0 he was free to move things forwards again, but it made the statement that he was fairly happy with the shape of the framework. I think you would gain a lot of momentum with Nitro if you (and some of the more enthusiastic writers!) were to start documenting how you think Nitro should be used, and then committing to "not break the wiki", sort of thing. Cheers, Dan ps. You will also find that some people will self-select as "wiki gnomes", keeping the place tidy and making sure the content is reasonably consistent. I don't know where they come from, but I have eternal respect for them. George Moschovitis wrote: > > there used to be a Nitro wiki, wich I personally think would be > fantastic. > Oxywtf is great to have, but there's something organic about wikis > that > just can't be found elsewhere. > > > I will bring back the wiki. I am not sure though, should I make the > wiki writeable by everyone? or give write access only to selected > members of the community. Moreover, we would need some guidelines, ie > how to organize this wiki. Can anyone in this ml suggest a good set of > guidelines? > > -g. > > -- > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > ------------------------------------------------------------------------ > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070614/cdd31e4d/attachment.html From arne at arnebrasseur.net Fri Jun 15 03:49:28 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Fri, 15 Jun 2007 00:49:28 -0700 (PDT) Subject: [Nitro] Newbie Impressions In-Reply-To: <4671BBD7.2070307@tastapod.com> References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> <4671BBD7.2070307@tastapod.com> Message-ID: <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> Hi Dan, Manveru, Jonathan, George and I had a discussion on IRC yesterday about the state and future of Nitro. George has put an awful lot of work in it, and a lot has been done since 0.42, but he seems to have the feeling he's a bit on his own getting little outside help. It's all a bit of a sad situation. The repo version looks really good but needs polish and specs. The gem version is getting outdated so we really should work on getting 0.50 out. That would give us a solid base to move forward from. I have committed myself to write the specs (rspec), Jonathan will review them. George will finish the examples, and if we pull this off and release a decent 0.50 he has said to release some other nifty stuff related to Nitro. That said I personally also feel docs would be very important. I believe this community would've been a lot bigger and more vibrant if the barrier to entry would have been lower thanks to decent documentation. But I'm gonna work on the specs first, since they should form a good starting point for anyone writing docs. If G could bring back the wiki it would still be a valuable tool, for both developers and users, but I'm very fond of wikis so I'm biased :). To anyone listening : please give the repo version a shot (darcs get http://repo.nitroproject.org). The API will probably not change much till 0.50. (That is correct, is it George?) So now is the time to hunt for those bugs, however small. Let us know what problems you encounter. If some people don't have darcs access I will try to set up a daily snapshot of sorts. Just make yourself known on the list. Thank you for listening. (ab) > Hi George. > > I would suggest keeping the wiki public, and then think about locking it > down if it gets abused (which is unlikely). > > DHH did a very smart thing in the run-up to Rails 1.0, which was that he > committed to "not break the book". In other words, the RoR book - which > was published to coincide with the 1.0 release - would be the reference > point and the development team would not break compatibility with > anything in it. After 1.0 he was free to move things forwards again, but > it made the statement that he was fairly happy with the shape of the > framework. > > I think you would gain a lot of momentum with Nitro if you (and some of > the more enthusiastic writers!) were to start documenting how you think > Nitro should be used, and then committing to "not break the wiki", sort > of thing. > > Cheers, > Dan > > ps. You will also find that some people will self-select as "wiki > gnomes", keeping the place tidy and making sure the content is > reasonably consistent. I don't know where they come from, but I have > eternal respect for them. > > > George Moschovitis wrote: >> >> there used to be a Nitro wiki, wich I personally think would be >> fantastic. >> Oxywtf is great to have, but there's something organic about wikis >> that >> just can't be found elsewhere. >> >> >> I will bring back the wiki. I am not sure though, should I make the >> wiki writeable by everyone? or give write access only to selected >> members of the community. Moreover, we would need some guidelines, ie >> how to organize this wiki. Can anyone in this ml suggest a good set of >> guidelines? >> >> -g. >> >> -- >> http://phidz.com >> http://blog.gmosx.com >> http://cull.gr >> http://www.joy.gr >> http://nitroproject.org >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Nitro-general mailing list >> Nitro-general at rubyforge.org >> http://rubyforge.org/mailman/listinfo/nitro-general > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general From arne at arnebrasseur.net Fri Jun 15 08:48:54 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Fri, 15 Jun 2007 05:48:54 -0700 (PDT) Subject: [Nitro] [PATCH] beginning of a rake file Message-ID: <4636.81.245.188.157.1181911734.squirrel@webmail.arnebrasseur.net> From arne at arnebrasseur.net Fri Jun 15 08:56:40 2007 From: arne at arnebrasseur.net (arne at arnebrasseur.net) Date: Fri, 15 Jun 2007 05:56:40 -0700 (PDT) Subject: [Nitro] [PATCH] beginning of a rake file Message-ID: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> I'm looking at the best way to organise the test/spec infrastructure, but something with a rakefile seems the way to go. To that end I created a rakefile and a rake_tasks directory, and moved the most obvious stuff from script/ to rake_tasks/ So issuing rake -T now gives you rake cleanup:all # Perform all cleanup tasks rake cleanup:cache # Cleanup caches rake cleanup:dist # Cleanup distribution dirs rake cleanup:misc # cleanup miscelanious files rake cleanup:rdoc # Cleanup rDoc directories rake darcs:apply # Apply a patch bundle to the darcs repository rake dist # Create gem and zip distributions rake tabs # Convert tabs to spaces and \r\n to \n script/cleanup.rb script/build.rb script/ctabs.rb script/apply.rb have been replaced with rake_tasks/cleanup.rake rake_tasks/dist.rake rake_tasks/tabs.rake rake_tasks/apply.rake The only thing is that with rake it's not so easy to pass additional command line arguments to your tasks, AFAIK. So for apply i resorted to using environment variables : BUNDLE=some_bundle rake darcs:apply As said a rake_tasks/spec.rake is coming, I'm looking at the rspec rake tasks, and at how Ramaze does it since they don't use the rSpec task. Sorry for the empty mail. (ab) -------------- next part -------------- A non-text attachment was scrubbed... Name: rake_init.patch.tar.gz Type: application/gzip Size: 13640 bytes Desc: not available Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070615/14cc791d/attachment.bin From john at oxyliquit.de Fri Jun 15 11:01:39 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 15 Jun 2007 18:01:39 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, only short notice, I like it. I think too that Rake is the way to go here, and love you seeing giving the overal structure some lovin' ! Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From john at oxyliquit.de Fri Jun 15 11:36:19 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Fri, 15 Jun 2007 18:36:19 +0300 Subject: [Nitro] Newbie Impressions In-Reply-To: <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> <4671BBD7.2070307@tastapod.com> <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, thank you very much for that comprehensive post and summarizing the gist of the irc discussion. I'm going to work on Og specs, which hopefully goes smoother this time now that you have made some 'pre work' by creating a Rakefile. Where I can predict problems, is 'store problems' introduced by the new store pool. Other than that, there could also be problems in the relation deletion. The rest (I hope) consists mostly of smaller problems. So, anyone willing to induce some _life_ into Og again, I already agreed to review any patches you want me to. Even if you feel like being too new too help or just too shy. :P The best way to get better in touch with me: IRC: #nitro on irc.freenode.net I also do live help, I can help you get started with Nitro, walk you through the basic Nitro app generation and give extensive Og help. So, if you feel like stuck, or unsure on how you start, want to 'sidestep' non-existant documenation, come see me. ;) Jo -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From george.moschovitis at gmail.com Fri Jun 15 11:57:14 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 15 Jun 2007 18:57:14 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: This looks nice :) I am glad you are taking the specs thing seriously! -g. On 6/15/07, arne at arnebrasseur.net wrote: > > I'm looking at the best way to organise the test/spec infrastructure, but > something with a rakefile seems the way to go. To that end I created a > rakefile and a rake_tasks directory, and moved the most obvious stuff from > script/ to rake_tasks/ > > So issuing rake -T now gives you > rake cleanup:all # Perform all cleanup tasks > rake cleanup:cache # Cleanup caches > rake cleanup:dist # Cleanup distribution dirs > rake cleanup:misc # cleanup miscelanious files > rake cleanup:rdoc # Cleanup rDoc directories > rake darcs:apply # Apply a patch bundle to the darcs repository > rake dist # Create gem and zip distributions > rake tabs # Convert tabs to spaces and \r\n to \n > > script/cleanup.rb > script/build.rb > script/ctabs.rb > script/apply.rb > > have been replaced with > > rake_tasks/cleanup.rake > rake_tasks/dist.rake > rake_tasks/tabs.rake > rake_tasks/apply.rake > > The only thing is that with rake it's not so easy to pass additional > command line arguments to your tasks, AFAIK. So for apply i resorted to > using environment variables : > > BUNDLE=some_bundle rake darcs:apply > > As said a rake_tasks/spec.rake is coming, I'm looking at the rspec rake > tasks, and at how Ramaze does it since they don't use the rSpec task. > > Sorry for the empty mail. > > (ab) > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- 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/20070615/466ed562/attachment-0001.html From george.moschovitis at gmail.com Fri Jun 15 12:01:36 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 15 Jun 2007 19:01:36 +0300 Subject: [Nitro] Newbie Impressions In-Reply-To: <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> <4671BBD7.2070307@tastapod.com> <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> Message-ID: > > http://repo.nitroproject.org). The API will probably not change much till > 0.50. (That is correct, is it George?) So now is the time to hunt for > That is *correct*. -g. -- 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/20070615/74b8759b/attachment.html From george.moschovitis at gmail.com Fri Jun 15 12:02:47 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 15 Jun 2007 19:02:47 +0300 Subject: [Nitro] Newbie Impressions In-Reply-To: References: <466F109D.60601@arnebrasseur.net> <9e03c3c60706122241i30e0bf22se483ac2db9b38649@mail.gmail.com> <2936.81.246.186.164.1181722037.squirrel@webmail.arnebrasseur.net> <4671BBD7.2070307@tastapod.com> <3350.81.245.188.157.1181893768.squirrel@webmail.arnebrasseur.net> Message-ID: I will work on the blog example over the weekend and make sure it runs and demonstrates most of the latest changes. -g. On 6/15/07, George Moschovitis wrote: > > http://repo.nitroproject.org). The API will probably not change much till > > 0.50. (That is correct, is it George?) So now is the time to hunt for > > > > That is *correct*. > > -g. > > -- > http://phidz.com > http://blog.gmosx.com > http://cull.gr > http://www.joy.gr > http://nitroproject.org > -- 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/20070615/480bdfb3/attachment.html From john at oxyliquit.de Sat Jun 16 02:44:44 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 16 Jun 2007 09:44:44 +0300 Subject: [Nitro] Helping to polish the nitroproject web page In-Reply-To: <4b6f054f0706121716u55adf6bdjbd1b9f0b29764c74@mail.gmail.com> References: <4b6f054f0706121716u55adf6bdjbd1b9f0b29764c74@mail.gmail.com> Message-ID: Hi Trans, > I resized the image to fit the small box above the "what's new" image > on the nitroproject.org web page. Could we get it added with a link. thanks for caring for Oxyliquit ^_^ Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Jun 16 07:08:28 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 16 Jun 2007 14:08:28 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, I have started converting test cases. Progress can be monitored here: http://oxywtf.de/~john/darcs_repos/glycerin There's also the patch from Arne included. He's actively working on a better infrastructure atm. I use the following 'transition approach' I `darcs mv` tc_* files to the respective directory in the spec/ folder and from there start modifying (crudely for now, fixing comes later). Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sat Jun 16 08:46:21 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 16 Jun 2007 15:46:21 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Ok, I applied the patch. One suggestion, I would like that you change 'rake_tasks' to simply 'rake'. what do you think? -g. On 6/15/07, arne at arnebrasseur.net wrote: > > I'm looking at the best way to organise the test/spec infrastructure, but > something with a rakefile seems the way to go. To that end I created a > rakefile and a rake_tasks directory, and moved the most obvious stuff from > script/ to rake_tasks/ > > So issuing rake -T now gives you > rake cleanup:all # Perform all cleanup tasks > rake cleanup:cache # Cleanup caches > rake cleanup:dist # Cleanup distribution dirs > rake cleanup:misc # cleanup miscelanious files > rake cleanup:rdoc # Cleanup rDoc directories > rake darcs:apply # Apply a patch bundle to the darcs repository > rake dist # Create gem and zip distributions > rake tabs # Convert tabs to spaces and \r\n to \n > > script/cleanup.rb > script/build.rb > script/ctabs.rb > script/apply.rb > > have been replaced with > > rake_tasks/cleanup.rake > rake_tasks/dist.rake > rake_tasks/tabs.rake > rake_tasks/apply.rake > > The only thing is that with rake it's not so easy to pass additional > command line arguments to your tasks, AFAIK. So for apply i resorted to > using environment variables : > > BUNDLE=some_bundle rake darcs:apply > > As said a rake_tasks/spec.rake is coming, I'm looking at the rspec rake > tasks, and at how Ramaze does it since they don't use the rSpec task. > > Sorry for the empty mail. > > (ab) > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > > -- 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/20070616/7fbc896a/attachment.html From john at oxyliquit.de Sat Jun 16 09:10:24 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 16 Jun 2007 16:10:24 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, > Ok, I applied the patch. One suggestion, I would like that you change > 'rake_tasks' to simply 'rake'. > what do you think? I would leave them as rake_tasks, as it's just clearer (from outside) what the folder contains. Besides that, Arne and I have discovered a potential conflict with RSpec: The Nitro Aspects implementation overrides `before` for any Module, but RSpec depends on its own `before`. Could that have any side effects using those two together? I'm just in the middle of translating more tcs, one thing that doesn't work is Cacheable. The `after_enchant` callback doesn't seem to get called, but I didn't investigate further. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From john at oxyliquit.de Sat Jun 16 10:36:05 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 16 Jun 2007 17:36:05 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, more patches out. One thing to note here is: I'm only testing via PostgreSQL. So I need one or two guys to test Sqlite and Mysql. Volunteers? Atm every second spec fails, and many specs to go, but my head hurts for the day, so.. but, anyone having patches reviewed, I'm still here. George, I need you help on the join.rb spec, I assume you have written the original test, and I can't see what it tries to do. It fails (for me) on the first test. I'd love you to have a look if I translated it correctly from the TC (I'm not that good with specs yet) or if there's indeed a problem within Og. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From transfire at gmail.com Sat Jun 16 16:00:32 2007 From: transfire at gmail.com (Trans) Date: Sat, 16 Jun 2007 20:00:32 -0000 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: <1182024032.399085.79990@p77g2000hsh.googlegroups.com> On Jun 15, 8:56 am, a... at arnebrasseur.net wrote: > I'm looking at the best way to organise the test/spec infrastructure, but > something with a rakefile seems the way to go. To that end I created a > rakefile and a rake_tasks directory, and moved the most obvious stuff from > script/ to rake_tasks/ > > So issuing rake -T now gives you > rake cleanup:all # Perform all cleanup tasks > rake cleanup:cache # Cleanup caches > rake cleanup:dist # Cleanup distribution dirs > rake cleanup:misc # cleanup miscelanious files > rake cleanup:rdoc # Cleanup rDoc directories > rake darcs:apply # Apply a patch bundle to the darcs repository > rake dist # Create gem and zip distributions > rake tabs # Convert tabs to spaces and \r\n to \n > > script/cleanup.rb > script/build.rb > script/ctabs.rb > script/apply.rb > > have been replaced with > > rake_tasks/cleanup.rake > rake_tasks/dist.rake > rake_tasks/tabs.rake > rake_tasks/apply.rake > > The only thing is that with rake it's not so easy to pass additional > command line arguments to your tasks, AFAIK. So for apply i resorted to > using environment variables : > > BUNDLE=some_bundle rake darcs:apply > > As said a rake_tasks/spec.rake is coming, I'm looking at the rspec rake > tasks, and at how Ramaze does it since they don't use the rSpec task. > > Sorry for the empty mail. I'll probably be the lone dissenter here, but I prefer script/. I realize that Rake provides some useful features in the construction of project tasks, but Rakefiles also have a tendency to get pretty ugly. Scripts remain clean, and can require common behavior from a shared script-lib. Also, I have been working on some utilities which make working with scripts more fruitful, such a 'ludo' (lookup and do) and Scriptable. In any case, Rake's a fine choice, of course. It's just not my preference. Perhaps when my script tools are polished enough we can revisit this. I'm sure the Rakefile will be quite obese by then ;-) T. From john at oxyliquit.de Sat Jun 16 16:12:51 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sat, 16 Jun 2007 23:12:51 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <1182024032.399085.79990@p77g2000hsh.googlegroups.com> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> <1182024032.399085.79990@p77g2000hsh.googlegroups.com> Message-ID: Hi, > I'll probably be the lone dissenter here, but I prefer script/. I > realize that Rake provides some useful features in the construction of > project tasks, but Rakefiles also have a tendency to get pretty ugly. > Scripts remain clean, and can require common behavior from a shared > script-lib. Also, I have been working on some utilities which make > working with scripts more fruitful, such a 'ludo' (lookup and do) and > Scriptable. > > In any case, Rake's a fine choice, of course. It's just not my > preference. Perhaps when my script tools are polished enough we can > revisit this. I'm sure the Rakefile will be quite obese by then ;-) we just need a working system which plays nice for now and does what we want: stable running of some task, testing being the premier one. We've got help from Manveru here where we got a structure from, where single scripts get loaded from a subdirectory. This makes for a cleaner structure than a huge Rakefile at least. All I care about really is: easy running, easy working with errors, easy spotting of errors, being able to run single specs by hand. So for what I care it could've stayed with script, but those weren't working, so whatever system is fine by me, just gotta work. :P Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From reid.thompson at ateb.com Sat Jun 16 23:27:28 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Sat, 16 Jun 2007 23:27:28 -0400 Subject: [Nitro] [Fwd: Re: [GENERAL] INSERT ... RETURNING in v8.2] Message-ID: <4674AA20.3010704@ateb.com> of interest... -------- Original Message -------- Subject: Re: [GENERAL] INSERT ... RETURNING in v8.2 Date: Sat, 16 Jun 2007 08:02:41 -0400 From: Tom Allison To: Vincenzo Romano CC: pgsql-general at postgresql.org References: <200706121618.32613.vincenzo.romano at gmail.com> On Jun 12, 2007, at 10:18 AM, Vincenzo Romano wrote: > > Hi all. > I'm trying to use this wonderful feature (thanks to anyone who > suggested/committed/implemented it). > > According to the documentation: > (http://www.postgresql.org/docs/8.2/interactive/sql-insert.html) > > "The optional RETURNING clause causes INSERT to compute and return > value(s) based on each row actually inserted. This is primarily > useful for obtaining values that were supplied by defaults, such > as a serial sequence number. However, any expression using the > table's columns is allowed. The syntax of the RETURNING list is > identical to that of the output list of SELECT." Holy Crud! you mean to tell me I can replace: insert into table(string) values(('one'),('two'),('three')); select idx from table where string in ('one','two','three'); with insert into table(string) values(('one'),('two'),('three')) returning idx; ????? I realize that this is an extension to standard SQL but it sure would save me a lot. I'm wondering just how many other things I'm missing.... (I am really starting to like this database more every week) ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend From reid.thompson at ateb.com Sat Jun 16 23:28:45 2007 From: reid.thompson at ateb.com (Reid Thompson) Date: Sat, 16 Jun 2007 23:28:45 -0400 Subject: [Nitro] [Fwd: Re: [GENERAL] INSERT ... RETURNING in v8.2] Message-ID: <4674AA6D.8050109@ateb.com> of interest, cont. -------- Original Message -------- Subject: Re: [GENERAL] INSERT ... RETURNING in v8.2 Date: Sat, 16 Jun 2007 18:04:08 +0200 From: PFC To: Tom Allison , Vincenzo Romano CC: pgsql-general at postgresql.org References: <200706121618.32613.vincenzo.romano at gmail.com> <8E77CF32-BFEF-4254-999B-5104A574D0E7 at tacocat.net> > Holy Crud! > you mean to tell me I can replace: > > insert into table(string) values(('one'),('two'),('three')); > select idx from table where string in ('one','two','three'); Yes. A smart ORM library should, when you create a new database object from form values, use INSERT RETURNING to grab all the default values (SERIALs, DEFAULTs, trigger-generated stuff etc). This is much more elegant than digging to find the sequence name to currval() it ! I think this feature is priceless (but it would be even better if I could do INSERT INTO archive (DELETE FROM active WHERE blah RETURNING *) ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings From john at oxyliquit.de Sun Jun 17 05:15:52 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 17 Jun 2007 12:15:52 +0300 Subject: [Nitro] [Fwd: Re: [GENERAL] INSERT ... RETURNING in v8.2] In-Reply-To: <4674AA6D.8050109@ateb.com> References: <4674AA6D.8050109@ateb.com> Message-ID: Hi, > of interest, cont. yes, very much of interest! :D >> Holy Crud! >> you mean to tell me I can replace: >> >> insert into table(string) values(('one'),('two'),('three')); >> select idx from table where string in ('one','two','three'); But actually Og doesn't do that (because it's crap), it'd only be very nice as it removes some complexity around the insertion. But, being a nice ORM, Og will have to support older databases, meaning 7.4 will still be floating around, so it'll take 10 years until we can remove that complexity. -_- Ah well, still, _very_ nice feature, thank you for reporting! Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From arne at arnebrasseur.net Sun Jun 17 06:40:53 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 17 Jun 2007 12:40:53 +0200 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: <46750FB5.9080006@arnebrasseur.net> >> Ok, I applied the patch. One suggestion, I would like that you change >> 'rake_tasks' to simply 'rake'. >> what do you think? >> > > I would leave them as rake_tasks, as it's just clearer (from outside) > what the folder contains. > I'm fine either way. (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20070617/d77e0615/attachment.html From arne at arnebrasseur.net Sun Jun 17 06:51:52 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 17 Jun 2007 12:51:52 +0200 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <1182024032.399085.79990@p77g2000hsh.googlegroups.com> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> <1182024032.399085.79990@p77g2000hsh.googlegroups.com> Message-ID: <46751248.609@arnebrasseur.net> Trans schreef: > In any case, Rake's a fine choice, of course. It's just not my > preference. Perhaps when my script tools are polished enough we can > revisit this. I'm sure the Rakefile will be quite obese by then ;-) > Actually the rakefile contains only one line of code : Dir["rake_tasks/*.rake"].each &method(:load) so I wouldn't go as far as to call it obese :p The *.rake files are essentially the files from script/ with a desc/task wrapped around. I'd be glad to revisit this later if you propose a solid alternative. Two things about rake appeal to me : rake -T one instant overview of what tasks are available, so nicely self-documenting, and second the dependency system. (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From george.moschovitis at gmail.com Sun Jun 17 07:03:33 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 17 Jun 2007 14:03:33 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: <46750FB5.9080006@arnebrasseur.net> References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> <46750FB5.9080006@arnebrasseur.net> Message-ID: > > I'm fine either way. > ok, lets leave it as 'rake_tasks' for the moment... -g. -- 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/20070617/2f880872/attachment.html From arne at arnebrasseur.net Sun Jun 17 07:16:17 2007 From: arne at arnebrasseur.net (Arne Brasseur) Date: Sun, 17 Jun 2007 13:16:17 +0200 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> <46750FB5.9080006@arnebrasseur.net> Message-ID: <46751801.4040807@arnebrasseur.net> George Moschovitis schreef: > ok, lets leave it as 'rake_tasks' for the moment... I've given it some more thought, and I think 'rake' is too generic, one might get the impression we're bundling our own version of rake. Especially since it sits next to raw/og/nitro. So rake_tasks +1 (ab) -- Arne Brasseur @ your service http://www.arnebrasseur.net arne at arnebrasseur.net +32/496/94.55.63 From john at oxyliquit.de Sun Jun 17 07:56:26 2007 From: john at oxyliquit.de (Jonathan Buch) Date: Sun, 17 Jun 2007 14:56:26 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: Hi, > George, I need you help on the join.rb spec, I assume you have don't worry about this, I found a bug in postgresql which caused my problems. Jo -- Feel the love http://pinkjuice.com/pics/ruby.png From george.moschovitis at gmail.com Sun Jun 17 08:03:09 2007 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 17 Jun 2007 15:03:09 +0300 Subject: [Nitro] [PATCH] beginning of a rake file In-Reply-To: References: <4640.81.245.188.157.1181912200.squirrel@webmail.arnebrasseur.net> Message-ID: great ;-) I love problems