From ilias at lazaridis.com Mon May 2 13:15:19 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Mon, 02 May 2005 20:15:19 +0300 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? Message-ID: As I got no feedback on this list, I tried to look to the actual code-repository. where can I find it? . -- http://lazaridis.com From ilias at lazaridis.com Mon May 2 15:32:13 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Mon, 02 May 2005 22:32:13 +0300 Subject: [Nitro] [OG] - Automated table modification / extension In-Reply-To: References: Message-ID: Ilias Lazaridis wrote: [...] > How do I setup OG that it automaticaly match the table to the updated > class-definition? (= automaticly add columns). the following code, added to sqlite.rb add a newly created simple field: - #--------------------------------------------------------------------------- def table_fields(klass, db) # returns array of fields, as returned by sqlite3 adapter # ["4", "oid", "integer", "0", nil, "1"] conn = db.get_connection() tfields = [] begin conn.store.table_info( klass::DBTABLE ) {|field| tfields << field } rescue Exception => ex # exception handling end return tfields end #--------------------------------------------------------------------------- def table_field_count(klass, db) # returns number of fields defined in a table, 0 if none (table non-existent) conn = db.get_connection() counter = 0 begin conn.store.table_info( klass::DBTABLE) {|field| counter += 1 } rescue Exception => ex #TODO exception handling end return counter end #--------------------------------------------------------------------------- def field_exists(field, tfield) p tfield val = tfield[1] + ' ' + tfield[2] if val == field return true else return false end end #--------------------------------------------------------------------------- def table_evolve(klass, db) conn = db.get_connection fields = create_fields(klass) tfields = table_fields(klass, db) sql = "" for idx in (0 .. fields.size - 2) # ommit OID if not field_exists(fields[idx], tfields[idx]) Logger.debug "add field: #{fields[idx]}" sql << "ALTER TABLE #{klass::DBTABLE} ADD #{fields[idx]};" end end begin if not sql == "" conn.query(sql).close conn.query("VACUUM ;").close end rescue Exception => ex p ex.to_s() end end #-------------------------------------------------------------------------- def create_table(klass, db) conn = db.get_connection fields = create_fields(klass) table_evolve(klass, db) [...] add table_evolve - due to the missing feedback, this has taken me excessive amounts of time (estimated 4 times more than with feedback). - As stated, OID should be placed as the first field . -- http://lazaridis.com From ilias at lazaridis.com Tue May 3 11:54:23 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Tue, 03 May 2005 18:54:23 +0300 Subject: [Nitro] [OG] - Object Orientation of Sources Message-ID: I've seen some talks about AOP (Aspect Oriented Programming). But: the current sources of OG are not very object oriented, althoug ruby provides the constructs to code things straightforward. I like to suggest to make a clean OO refactoring, before moving on to other programming techniques. It is important that intressents understand the source-code quickly, thus they can become contributors. . -- http://lazaridis.com From ilias at lazaridis.com Tue May 3 16:20:04 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Tue, 03 May 2005 23:20:04 +0300 Subject: [Nitro] [OG] - has_one relation Message-ID: the "has_many" relation class Driver prop_accessor :name, String prop_accessor :proficiency, String belongs_to :car, Car end class Car prop_accessor :manufacturer, String prop_accessor :model, String prop_accessor :modelYear, Fixnum prop_accessor :new1, Fixnum has_many :driver, Driver end - d = Driver['Peter'] c = Car[1] c.add_driver( d ) c.save() - How do I model/access "has_one" relation? . -- http://lazaridis.com From george.moschovitis at gmail.com Wed May 4 05:15:41 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 12:15:41 +0300 Subject: [Nitro] [OG] - Object Orientation of Sources In-Reply-To: References: Message-ID: > I like to suggest to make a clean OO refactoring, before moving on to > other programming techniques. the new code, to be released early next week is extensively refactored and clean. -g. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Wed May 4 05:16:19 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 12:16:19 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: > How do I model/access "has_one" relation? just use has_one -g. -- http://nitro.rubyforge.org http://www.joy.gr From ilias at lazaridis.com Wed May 4 05:25:52 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 12:25:52 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: George Moschovitis wrote: >>How do I model/access "has_one" relation? > > just use has_one this fails, thus i'm asking: can you please make the necessary additions to the code? class Driver prop_accessor :name, String prop_accessor :proficiency, String end class Car prop_accessor :manufacturer, String prop_accessor :model, String prop_accessor :modelYear, Fixnum prop_accessor :new1, Fixnum has_one :driver, Driver end - d = Driver['Peter'] c = Car[1] # this assignment fails: c.add_driver( d ) c.save() . -- http://lazaridis.com From george.moschovitis at gmail.com Wed May 4 05:31:42 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 12:31:42 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: you have to add: class Driver belongs_to :car, Car end -g. -- http://nitro.rubyforge.org http://www.joy.gr From ilias at lazaridis.com Wed May 4 05:30:06 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 12:30:06 +0300 Subject: [Nitro] [OG] - Object Orientation of Sources In-Reply-To: References: Message-ID: George Moschovitis wrote: >>I like to suggest to make a clean OO refactoring, before moving on to >>other programming techniques. > > the new code, to be released early next week is extensively refactored > and clean. this was to be released this week. - Where can I found the code-repository or at least a snapshot? . -- http://lazaridis.com From ilias at lazaridis.com Wed May 4 05:42:29 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 12:42:29 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: George Moschovitis wrote: > you have to add: > > class Driver > belongs_to :car, Car > end still the same, see below (using og 0.16) . class Driver prop_accessor :name, String prop_accessor :proficiency, String belongs_to :car, Car end class Car prop_accessor :manufacturer, String prop_accessor :model, String prop_accessor :modelYear, Fixnum prop_accessor :new1, Fixnum has_one :driver, Driver end - d = Driver['Peter'] c = Car[1] c.add_driver( d ) # => Exception: undefined method `add_driver' for # c.save() > > -g. > -- http://lazaridis.com From george.moschovitis at gmail.com Wed May 4 05:48:13 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 12:48:13 +0300 Subject: [Nitro] [OG] - Object Orientation of Sources In-Reply-To: References: Message-ID: > this was to be released this week. Developing the new version of Og is not easy, the new features are quite advanced, and the refactoring takes time. Be patient. There is no public repository at the moment. -g. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Wed May 4 05:49:50 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 12:49:50 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: Send me privately (email) the full programm and I 'll have a look, you probably haven't intialised Og correctly or something. -g. -- http://nitro.rubyforge.org http://www.joy.gr From ilias at lazaridis.com Wed May 4 08:08:01 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 15:08:01 +0300 Subject: [Nitro] [OG] - Object Orientation of Sources In-Reply-To: References: Message-ID: George Moschovitis wrote: >>this was to be released this week. > > > Developing the new version of Og is not easy, the new features are > quite advanced, and the refactoring takes time. Be patient. I am not patient. That's why I started developing the extensions I need (to which I go _zero_ feedback on this list). > There is no public repository at the moment. This is an inacceptable status. You should respect the time of your early adopters. alternatively you can of course "close" this project, until is ripe nouth to be published. But an public repository is essential. . -- http://lazaridis.com From ilias at lazaridis.com Wed May 4 08:49:09 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 15:49:09 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: George Moschovitis wrote: > Send me privately (email) the full programm and I 'll have a look, you > probably haven't intialised Og correctly or something. I am wondering more and more about you and this project: "c.add_driver( d )" _cannot_ work in an "has_one" relation. According to the code (0.16), the class is not 'enchanted' with "add_driver" please review the code from "meta.rb": - # Implements a 'has_one' relation. # Automatically enchants the calling class with helper methods. # # Example: # # class MyObject # has_one :child, TheClass # has_one :article # end # # creates the code: # # ... def has_one(name, klass = nil, options = {}) # linkback is the property of the child object that 'links back' # to this object. linkback = (options[:linkback].to_s || "#{MetaUtils.expand(self)}_oid").to_s meta :descendants, klass, linkback meta :props_and_relations, HasOne.new(name, klass, options) module_eval %{ def #{name}(extrasql = nil) Og.db.select_one("SELECT * FROM #{Og::Adapter.table(klass)} WHERE #{linkback}=\#\@oid \#\{extrasql\}", #{klass}) end def delete_#{name}(extrasql = nil) Og.db.exec("DELETE FROM #{Og::Adapter.table(klass)} WHERE #{linkback}=\#\@oid \#\{extrasql\}") end } end . -- http://lazaridis.com From george.moschovitis at gmail.com Wed May 4 09:27:13 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 16:27:13 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: As I said many times I am working on a new version of Og. Among other things this new version does not generate add_xxx methods. Instead it supports 'live' collections. For example: article.comments << comment or article.comments.push(comment) or article.comments.add(comment) # alias instead of article.add_comment(comment) Apart from looking more elegant and more like standard Ruby code they allow for some nice new features (caching, support for join queries/eager asscoiations, etc). I read your email in a hurry and I didn't remember how has_one worked in 0.16.0. Thats why I told you to email me your code so I can review it later (I am at the office now, and quite busy...) So, you are right, the correct way to do this in 0.16.0 is: driver.car = car # driver belongs_to car and not car.add_driver(driver) George. -- http://nitro.rubyforge.org http://www.joy.gr From ilias at lazaridis.com Wed May 4 09:35:31 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 16:35:31 +0300 Subject: [Nitro] [OG] - has_one relation In-Reply-To: References: Message-ID: George Moschovitis wrote: > As I said many times I am working on a new version of Og. Among other > things this new version does not generate add_xxx methods. Instead it > supports 'live' collections. For example: > > article.comments << comment > or > article.comments.push(comment) > or > article.comments.add(comment) # alias very nice. > instead of > > article.add_comment(comment) dropping this is very positive, as it doesn't look like OOP. > Apart from looking more elegant and more like standard Ruby code they > allow for some nice new features (caching, support for join > queries/eager asscoiations, etc). ok > I read your email in a hurry and I didn't remember how has_one worked > in 0.16.0. Thats why I told you to email me your code so I can review > it later (I am at the office now, and quite busy...) So, you are > right, the correct way to do this in 0.16.0 is: > > driver.car = car # driver belongs_to car > > and not > > car.add_driver(driver) ok. thank's for the information. . -- http://lazaridis.com From paulha at aracnet.com Wed May 4 11:04:33 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Wed, 04 May 2005 08:04:33 -0700 Subject: [Nitro] [OG] - Nitro vs Rails In-Reply-To: References: Message-ID: <4278E481.6040302@aracnet.com> In comp.lang.ruby there was an interesting discussion of the difference in design process between ActiveRecord and Og. Opinion seemed to be that AR may be better suited where the DB already exists or an Agile methodology is in use. Definitely, AR would seem to lend itself to DB-driven applications. That seems to imply that Og is "non-agile", which I don't think is true. I do think it's fair to say that it's code-driven, which will seem strange to a DB guy. I'm wondering if it is possible to combine the useful features from both into one-- Even though AR adapts to the structure of the DB, if there are specialized relationships between tables the programmer has to add meta-information to define them. On the other hand, it would be convenient if Og could handle an existing table or added/deleted fields without recoding. I'm curious if it would be possible to build an adapter pattern that could fit AR under Og or Og under AR. :-) I feel an investigation project coming on... Paul From ilias at lazaridis.com Wed May 4 11:15:10 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Wed, 04 May 2005 18:15:10 +0300 Subject: [Nitro] [OG] - Nitro vs Rails In-Reply-To: <4278E481.6040302@aracnet.com> References: <4278E481.6040302@aracnet.com> Message-ID: PAUL HANCHETT wrote: > In comp.lang.ruby there was an interesting discussion of the difference [...] please post a new message when opening a new thread. thank you. . http://lazaridis.com From george.moschovitis at gmail.com Wed May 4 12:10:04 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 4 May 2005 19:10:04 +0300 Subject: [Nitro] [OG] - Nitro vs Rails In-Reply-To: <4278E481.6040302@aracnet.com> References: <4278E481.6040302@aracnet.com> Message-ID: Hello paul, thanks for pointing this out to me. Read my reply to c.l.r -g. > meta-information to define them. On the other hand, it would be > convenient if Og could handle an existing table or added/deleted fields > without recoding. some support for both is coming real soon now :) -g. -- http://nitro.rubyforge.org http://www.joy.gr From shalofin at gmail.com Wed May 4 14:45:16 2005 From: shalofin at gmail.com (Wayne Pierce) Date: Wed, 4 May 2005 14:45:16 -0400 Subject: [Nitro] How do I run an example? Message-ID: <4617fd6d05050411451805a11d@mail.gmail.com> I just downloaded Nitro, but can't figure out how to run an example. I've tried the following from inside the example folder: - nitro - nitro run.rb - ./run.rb (after 'chmod +x run.rb') - nitro -h - nitro --help For starting out, where do I put files at? The documentation said to put them in the 'public', but where is that if I use WebBrick? I noticed a 'public' directory for each of the examples, should I recreate the directory structure somewhere that I want to be my web root? I guess the real question is where to start once I have installed the gem... Thanks, Wayne From alang at cronosys.com Wed May 4 14:48:44 2005 From: alang at cronosys.com (Alan Garrison) Date: Wed, 04 May 2005 14:48:44 -0400 Subject: [Nitro] How do I run an example? In-Reply-To: <4617fd6d05050411451805a11d@mail.gmail.com> References: <4617fd6d05050411451805a11d@mail.gmail.com> Message-ID: <4279190C.9000009@cronosys.com> Wayne Pierce wrote: >I just downloaded Nitro, but can't figure out how to run an example. >I've tried the following from inside the example folder: > > - nitro > - nitro run.rb > - ./run.rb (after 'chmod +x run.rb') > - nitro -h > - nitro --help > >For starting out, where do I put files at? The documentation said to >put them in the 'public', but where is that if I use WebBrick? I >noticed a 'public' directory for each of the examples, should I >recreate the directory structure somewhere that I want to be my web >root? > >I guess the real question is where to start once I have installed the gem... > >Thanks, > >Wayne > > ruby run.rb -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From alang at cronosys.com Wed May 4 14:55:32 2005 From: alang at cronosys.com (Alan Garrison) Date: Wed, 04 May 2005 14:55:32 -0400 Subject: [Nitro] How do I run an example? In-Reply-To: <4617fd6d05050411451805a11d@mail.gmail.com> References: <4617fd6d05050411451805a11d@mail.gmail.com> Message-ID: <42791AA4.3010807@cronosys.com> Wayne Pierce wrote: >I just downloaded Nitro, but can't figure out how to run an example. >I've tried the following from inside the example folder: > > - nitro > - nitro run.rb > - ./run.rb (after 'chmod +x run.rb') > - nitro -h > - nitro --help > >For starting out, where do I put files at? The documentation said to >put them in the 'public', but where is that if I use WebBrick? I >noticed a 'public' directory for each of the examples, should I >recreate the directory structure somewhere that I want to be my web >root? > >I guess the real question is where to start once I have installed the gem... > >Thanks, > >Wayne > > Gah, hit "Send" too soon. Under the examples directory are some apps, run the "ruby run.rb" in one of those. WebBrick should already be on your system (Ruby will find it). You may want to copy an example app to "local" directory (e.g., no_xsl_blog) and run it in case it needs to write information back to the disk. ./no_xsl_blog ./no_xsl_blog/log ./no_xsl_blog/conf ./no_xsl_blog/conf/locales ./no_xsl_blog/lib ./no_xsl_blog/lib/blog ./no_xsl_blog/public ./no_xsl_blog/public/m "cd" to the ./no_xsl_blog and do a "ruby run.rb". -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From james_b at neurogami.com Wed May 4 15:36:51 2005 From: james_b at neurogami.com (James Britt) Date: Wed, 04 May 2005 12:36:51 -0700 Subject: [Nitro] [OG] - Nitro vs Rails In-Reply-To: <4278E481.6040302@aracnet.com> References: <4278E481.6040302@aracnet.com> Message-ID: <42792453.5080709@neurogami.com> PAUL HANCHETT wrote: > In comp.lang.ruby there was an interesting discussion of the difference > in design process between ActiveRecord and Og. Opinion seemed to be > that AR may be better suited where the DB already exists or an Agile > methodology is in use. Definitely, AR would seem to lend itself to > DB-driven applications. > > That seems to imply that Og is "non-agile", which I don't think is > true. I do think it's fair to say that it's code-driven, which will > seem strange to a DB guy. The documentation, articles, and general discussion around Rails and AR all (that I've seen at least) emphasize creating a scheme first and then deriving your objects. David Hansson described a development style where one can gradually add in tables fields in an iterative process. This is certainly an option, though I find it somewhat awkward having to shift back and forth between a Ruby coding session and a SQL editor or admin tool. It also presumes that you have already determined that the object belongs in a database. To each his own, but the Rails docs would do well to have some information describing alternative design and development techniques, such as the best way to start using Rails without a database, and how to add in or change a database during development. (Though, for all I know, that information is there, but is simply buried someplace.) (There was a similar discussion some months ago on the Rails devel list, where some folks argued for the object-then-database flow, as apposed to the objects-from-database of AR. David Hansson made the same argument he recently gave on c.l.r, but also, if I understand correctly, suggested that Rails may gain an Og-style approach as well. See [0] ) Whether Og or AR is more 'agile' is a non-issue; the word has a enough buzziness such that getting people to agree on a definition is , um, hard. I would expect people to at least spend some time with each (as well as Wee and any other reasonably robust framework) to decide what is the best fit for their style. I tend to find Nitro more agile, in that I can start with less code, fewer files, and fewer assumptions, and gradually work my way through an application, more so than with Rails, but I have to believe that the hard-core Railers have become accustomed to a style that allows them to do the same. Finally, I don't see this as Nitro vs Rails, but a matter of understanding where each works best, and picking the appropriate tool for any given task. James [0] http://article.gmane.org/gmane.comp.lang.ruby.rails/3720 From george.moschovitis at gmail.com Thu May 5 02:54:59 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 5 May 2005 09:54:59 +0300 Subject: [Nitro] How do I run an example? In-Reply-To: <42791AA4.3010807@cronosys.com> References: <4617fd6d05050411451805a11d@mail.gmail.com> <42791AA4.3010807@cronosys.com> Message-ID: > > "cd" to the ./no_xsl_blog and do a "ruby run.rb". no need to cd to the dir, just enter: ruby path/to/exampes/no_xsl_blog/run.rb and it will wok :) -g. -- http://nitro.rubyforge.org http://www.joy.gr From jos at catnook.com Thu May 5 02:08:12 2005 From: jos at catnook.com (Jos Backus) Date: Wed, 4 May 2005 23:08:12 -0700 Subject: [Nitro] http://nitro.rubyforge.org/ has a small spelling error Message-ID: <20050505060834.GA56282@lizzy.catnook.local> Hello, "Read the online documenation." should be "Read the online documentation.". Cheers, -- Jos Backus jos at catnook.com From ilias at lazaridis.com Thu May 5 17:06:33 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 00:06:33 +0300 Subject: [Nitro] [OG] - OID should be first field In-Reply-To: References: Message-ID: Ilias Lazaridis wrote: > George Moschovitis wrote: > >> On 4/30/05, Ilias Lazaridis wrote: >> >>> I'm wondering about some issues within the source-code. >>> >>> Shouldn't "OID" be the first filed within a table? >>> >> It would be nice, > > I think this is essential. !!! >> but I think this is hard to do. > > why? again, no answer. As expected: changing the code was trivial (and would have been much more trivial if I could have placed some questions). >> Btw, this less relevant in the new Og version which allows you to >> specify the >> primary key if you want. > > > I started to like the neutral entity "OID" - but having the flexibitily > to ommit it, is fine > > . > -- http://lazaridis.com From ilias at lazaridis.com Thu May 5 17:27:36 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 00:27:36 +0300 Subject: [Nitro] [OG] - 0.16.0 with automated table evolution Message-ID: I've finished a non-intrusive extension to og (addition of on file, og-evolve.rb, no original source code touched), which enables automated schema evolution (currently sqlite3 adapter). require 'og' require 'og-evolve' you can disable the extension by simply removing the "require" statement. - functionality: If you add a property to your object, a column is added to the underlying table. If anyone is intrested, I can sent the file via email. - [depending on the further delays of the next og version, I will possibly extend this extension.] . -- http://lazaridis.com From george.moschovitis at gmail.com Fri May 6 12:40:37 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 6 May 2005 19:40:37 +0300 Subject: [Nitro] Automatic finders Message-ID: Hello all, I was converting some features for the old Og to the new version. I just converted the automatic finders. In the old Og if you have a class: class User property :name, :description, String end you get some automatic finders like User.find_by_name(..) User.find_by_description(..) I am wondering if I should make the automatic finder generation explicit. IE, to get the method generated you should 'flag' this when defining the property: class User property :name, String, :finder => true property :description, String # no finder generated here end any opinions on this? At the moment the new Og automaticallly generates all finders. regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From ilias at lazaridis.com Fri May 6 13:03:11 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 20:03:11 +0300 Subject: [Nitro] Automatic finders In-Reply-To: References: Message-ID: George Moschovitis wrote: > Hello all, > > I was converting some features for the old Og to the new version. I > just converted the automatic finders. In the old Og if you have a > class: please place the code in a public repository, or at least provide a snapshot (zip / tar). > class User > property :name, :description, String > end > > you get some automatic finders like > > User.find_by_name(..) > User.find_by_description(..) > > I am wondering if I should make the automatic finder generation > explicit. IE, to get the method generated you should 'flag' this when > defining the property: > > class User > property :name, String, :finder => true > property :description, String # no finder generated here > end > > any opinions on this? At the moment the new Og automaticallly > generates all finders. > > > regards, > George. -- http://lazaridis.com From james_b at neurogami.com Fri May 6 13:11:26 2005 From: james_b at neurogami.com (James Britt) Date: Fri, 06 May 2005 10:11:26 -0700 Subject: [Nitro] Automatic finders In-Reply-To: References: Message-ID: <427BA53E.5090300@neurogami.com> George Moschovitis wrote: > I am wondering if I should make the automatic finder generation > explicit. IE, to get the method generated you should 'flag' this when > defining the property: > > class User > property :name, String, :finder => true > property :description, String # no finder generated here > end > > any opinions on this? At the moment the new Og automaticallly > generates all finders. What's the benefit to not generating them all the time? Speed? Is it possible to generate the method the first time it is called? (I'm sure this is possible, but is it practical?) James From alang at cronosys.com Fri May 6 13:13:20 2005 From: alang at cronosys.com (Alan Garrison) Date: Fri, 06 May 2005 13:13:20 -0400 Subject: [Nitro] Automatic finders In-Reply-To: References: Message-ID: <427BA5B0.9020703@cronosys.com> George Moschovitis wrote: >User.find_by_name(..) >User.find_by_description(..) > > > Can you just have one "generic" finder method per property? User.finder(:name, ..) User.finder(:description, ..) /n00b, so maybe I'm missing something -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From ilias at lazaridis.com Fri May 6 13:26:06 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 20:26:06 +0300 Subject: [Nitro] [OG] - 0.16.0 with automated table evolution In-Reply-To: References: Message-ID: Ilias Lazaridis wrote: > I've finished a non-intrusive extension to og (addition of on file, > og-evolve.rb, no original source code touched), which enables automated > schema evolution (currently sqlite3 adapter). > > require 'og' > require 'og-evolve' > > you can disable the extension by simply removing the "require" statement. > > - > > functionality: > > If you add a property to your object, a column is added to the > underlying table. > > If anyone is intrested, I can sent the file via email. I was contacted by Mr. Moschovitis to sent him the code. I've not send the code, as a method of protest against: * the non-existent public code-repository of OG * the non-public current redesing of OG * his answering behaviour on this forum (ignoring several topics) Collaboration is not to keep silence and to pick and include the results. Until this project will not become truly open, I'll not contribute to it's source-code-base. > [depending on the further delays of the next og version, I will possibly > extend this extension.] . -- http://lazaridis.com From paulha at aracnet.com Fri May 6 13:31:27 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Fri, 06 May 2005 10:31:27 -0700 Subject: [Nitro] Automatic finders In-Reply-To: References: Message-ID: <427BA9EF.308@aracnet.com> Is there an up-side to not generating them? If methods are generated in some cases and not in others, it becomes necessary to examine the /source /to determine what is available. That seems decidedly un-OOP like... Also, when a method is automatically generated, is there a way in Ruby for it to become visible? George Moschovitis wrote: >Hello all, > >I was converting some features for the old Og to the new version. I >just converted the automatic finders. In the old Og if you have a >class: > >class User > property :name, :description, String >end > >you get some automatic finders like > >User.find_by_name(..) >User.find_by_description(..) > >I am wondering if I should make the automatic finder generation >explicit. IE, to get the method generated you should 'flag' this when >defining the property: > >class User > property :name, String, :finder => true > property :description, String # no finder generated here >end > >any opinions on this? At the moment the new Og automaticallly >generates all finders. > > >regards, >George. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050506/de023e53/attachment.html From paulha at aracnet.com Fri May 6 13:45:15 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Fri, 06 May 2005 10:45:15 -0700 Subject: [Nitro] [OG] - 0.16.0 with automated table evolution In-Reply-To: References: Message-ID: <427BAD2B.8000903@aracnet.com> Ilias-- George is entitled to treat his code as he wants, just as you are entitled to contribute to the code base on his terms or not. Either contribute freely without strings attached, or do not and keep quiet about it. Your extensions were attractive until this attempt at blackmail. Now, I am not interested. Paul Ilias Lazaridis wrote: > Ilias Lazaridis wrote: > >> I've finished a non-intrusive extension to og (addition of on file, >> og-evolve.rb, no original source code touched), which enables >> automated schema evolution (currently sqlite3 adapter). >> >> require 'og' >> require 'og-evolve' >> >> you can disable the extension by simply removing the "require" >> statement. >> >> - >> >> functionality: >> >> If you add a property to your object, a column is added to the >> underlying table. >> >> If anyone is intrested, I can sent the file via email. > > > I was contacted by Mr. Moschovitis to sent him the code. > > I've not send the code, as a method of protest against: > > * the non-existent public code-repository of OG > * the non-public current redesing of OG > * his answering behaviour on this forum (ignoring several topics) > > Collaboration is not to keep silence and to pick and include the results. > > Until this project will not become truly open, I'll not contribute to > it's source-code-base. > >> [depending on the further delays of the next og version, I will >> possibly extend this extension.] > > > . > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050506/1502f165/attachment.html From craig-duncan at earthlink.net Fri May 6 13:52:55 2005 From: craig-duncan at earthlink.net (craig duncan) Date: Fri, 06 May 2005 13:52:55 -0400 Subject: [Nitro] Automatic finders In-Reply-To: <427BA5B0.9020703@cronosys.com> References: <427BA5B0.9020703@cronosys.com> Message-ID: <427BAEF7.8030802@earthlink.net> Alan Garrison wrote: > George Moschovitis wrote: > >> User.find_by_name(..) >> User.find_by_description(..) >> >> >> > Can you just have one "generic" finder method per property? > > User.finder(:name, ..) > User.finder(:description, ..) I like the latter much better. I don't like where method names cannot be documented except by explaining some pattern by which the method names will be generated, when there is a clearer alternative. Doesn't this latter method result in no additional method names needing to be generated for the purpose? How could that not be better? craig From alang at cronosys.com Fri May 6 13:54:35 2005 From: alang at cronosys.com (Alan Garrison) Date: Fri, 06 May 2005 13:54:35 -0400 Subject: [Nitro] Automatic finders In-Reply-To: <427BAEF7.8030802@earthlink.net> References: <427BA5B0.9020703@cronosys.com> <427BAEF7.8030802@earthlink.net> Message-ID: <427BAF5B.9000508@cronosys.com> craig duncan wrote: > Alan Garrison wrote: > >> George Moschovitis wrote: >> >>> User.find_by_name(..) >>> User.find_by_description(..) >>> >>> >>> >> Can you just have one "generic" finder method per property? >> >> User.finder(:name, ..) >> User.finder(:description, ..) > > > I like the latter much better. I don't like where method names cannot > be documented except by explaining some pattern by which the method > names will be generated, when there is a clearer alternative. Doesn't > this latter method result in no additional method names needing to be > generated for the purpose? How could that not be better? > > craig ...and I meant to type "instead of one per property" rather than "per property"... -- Alan Garrison Cronosys, LLC Phone: 216-221-4600 ext 308 From ilias at lazaridis.com Fri May 6 14:03:27 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 21:03:27 +0300 Subject: [Nitro] [OG] - 0.16.0 with automated table evolution In-Reply-To: <427BAD2B.8000903@aracnet.com> References: <427BAD2B.8000903@aracnet.com> Message-ID: PAUL HANCHETT wrote: > Ilias Lazaridis wrote: >> Ilias Lazaridis wrote: >> >>> I've finished a non-intrusive extension to og (addition of on file, >>> og-evolve.rb, no original source code touched), which enables >>> automated schema evolution (currently sqlite3 adapter). >>> >>> require 'og' >>> require 'og-evolve' >>> >>> you can disable the extension by simply removing the "require" >>> statement. >>> >>> - >>> >>> functionality: >>> >>> If you add a property to your object, a column is added to the >>> underlying table. >>> >>> If anyone is intrested, I can sent the file via email. >> >> I was contacted by Mr. Moschovitis to sent him the code. >> >> I've not send the code, as a method of protest against: >> >> * the non-existent public code-repository of OG >> * the non-public current redesing of OG >> * his answering behaviour on this forum (ignoring several topics) >> >> Collaboration is not to keep silence and to pick and include the results. >> >> Until this project will not become truly open, I'll not contribute to >> it's source-code-base. >> >>> [depending on the further delays of the next og version, I will >>> possibly extend this extension.] > > Ilias-- > > George is entitled to treat his code as he wants, just as you are > entitled to contribute to the code base on his terms or not. You are an specialist in stating the obvious facts. > Either > contribute freely without strings attached, or do not and keep quiet > about it. I insist on a open project to contribut code. Nothing special. > Your extensions were attractive until this attempt at blackmail. of course. > Now, I am not interested. You are still intrested, but your gigantic egoism don't let you admit it. btw: is your spam-list defect? . -- http://lazaridis.com From paulha at aracnet.com Fri May 6 14:07:13 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Fri, 06 May 2005 11:07:13 -0700 Subject: [Nitro] Automatic finders In-Reply-To: <427BAF5B.9000508@cronosys.com> References: <427BA5B0.9020703@cronosys.com> <427BAEF7.8030802@earthlink.net> <427BAF5B.9000508@cronosys.com> Message-ID: <427BB251.3050004@aracnet.com> One downside is that you can't use name completion to identify the availble finder methods. (Would it have been possible before?) Alan Garrison wrote: > craig duncan wrote: > >> Alan Garrison wrote: >> >>> George Moschovitis wrote: >>> >>>> User.find_by_name(..) >>>> User.find_by_description(..) >>>> >>>> >>>> >>> Can you just have one "generic" finder method per property? >>> >>> User.finder(:name, ..) >>> User.finder(:description, ..) >> >> >> >> I like the latter much better. I don't like where method names >> cannot be documented except by explaining some pattern by which the >> method names will be generated, when there is a clearer alternative. >> Doesn't this latter method result in no additional method names >> needing to be generated for the purpose? How could that not be better? >> >> craig > > > ...and I meant to type "instead of one per property" rather than "per > property"... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050506/0cce851a/attachment.html From ilias at lazaridis.com Fri May 6 16:51:41 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Fri, 06 May 2005 23:51:41 +0300 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: References: Message-ID: Ilias Lazaridis wrote: > As I got no feedback on this list, I tried to look to the actual > code-repository. > > where can I find it? the answer in another thread: "There is no public repository at the moment." what can one say. . -- http://lazaridis.com From kostas at nasis.com Fri May 6 17:04:36 2005 From: kostas at nasis.com (Kostas Nasis) Date: Fri, 06 May 2005 17:04:36 -0400 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: References: Message-ID: <427BDBE4.6050502@nasis.com> > the answer in another thread: > > "There is no public repository at the moment." > > what can one say. I think we'd all be happy if this one would shut up. Kostas From ilias at lazaridis.com Fri May 6 17:22:53 2005 From: ilias at lazaridis.com (Ilias Lazaridis) Date: Sat, 07 May 2005 00:22:53 +0300 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: <427BDBE4.6050502@nasis.com> References: <427BDBE4.6050502@nasis.com> Message-ID: Kostas Nasis wrote: > >> the answer in another thread: >> >> "There is no public repository at the moment." >> >> what can one say. > > I think we'd all be happy if this one would shut up. No chance, Mr. Bad Manners. - btw: A thread with an unanswered question is worthless. I've posted this here, thus the thread has at least some value. . -- http://lazaridis.com From james_b at neurogami.com Fri May 6 21:57:48 2005 From: james_b at neurogami.com (James Britt) Date: Fri, 06 May 2005 18:57:48 -0700 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: <427BDBE4.6050502@nasis.com> References: <427BDBE4.6050502@nasis.com> Message-ID: <427C209C.6040801@neurogami.com> Kostas Nasis wrote: > >> the answer in another thread: >> >> "There is no public repository at the moment." >> >> what can one say. > > > > I think we'd all be happy if this one would shut up. I agree. He's made himself unwelcome on other lists, and I'm disappointed to see him here. I have his mail filtered straight to trash. I'd prefer folks simply ignore him. James From george.moschovitis at gmail.com Sat May 7 02:22:55 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 May 2005 09:22:55 +0300 Subject: [Nitro] Automatic finders In-Reply-To: <427BAEF7.8030802@earthlink.net> References: <427BA5B0.9020703@cronosys.com> <427BAEF7.8030802@earthlink.net> Message-ID: > > User.finder(:description, ..) > > I like the latter much better. I don't like where method names cannot be > documented except by explaining some pattern by which the method names will be > generated, when there is a clearer alternative. Doesn't this latter method > result in no additional method names needing to be generated for the purpose? > How could that not be better? Hmm, this is interesting. It works just like the new selective update method I added: Instead of obj.update_properties('name = 'tml', hits = hits + 1') (ol Og) there is a new method: obj.name = 'tml' obj.hits += 1 obj.update(:name, :hits) that provides automatic quoting and is more suitable for non-sql stores. (of course the old og method is still working) So I 'll investigate your finder idea, thanks. But I prefer the find_xxx method, because specialized code can be pre-evaluated. And I really don't like to generate arrays all the time,I think Ruby's GC is pretty expensive at the moment. regards, George -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Sat May 7 02:29:16 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 May 2005 09:29:16 +0300 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: <427C209C.6040801@neurogami.com> References: <427BDBE4.6050502@nasis.com> <427C209C.6040801@neurogami.com> Message-ID: Ok, I added moderation to his account. I 'll accept only his useful messages and delete the excessive spam. Hope this helps to increase the SNR. -g. > > I think we'd all be happy if this one would shut up. > > I agree. He's made himself unwelcome on other lists, and I'm > disappointed to see him here. I have his mail filtered straight to trash. > > I'd prefer folks simply ignore him. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Sat May 7 02:40:33 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 May 2005 09:40:33 +0300 Subject: [Nitro] [OG] - 0.16.0 with automated table evolution In-Reply-To: <427BAD2B.8000903@aracnet.com> References: <427BAD2B.8000903@aracnet.com> Message-ID: > George is entitled to treat his code as he wants, just as you are entitled > ... > freely without strings attached, or do not and keep quiet about it. Thanks. BTW, there is a code repository for Nitro/Og that includes the latest version. This repository is open to a group of 5 developers that have given me valuable suggestions, bug reports through private emails. So there *are* people reviewing the new Og code. Moreover, I consider all the suggestions posted to this list. If anyone on this list *really* wants to see the latest code just send me an email and I can arrange this. But I would advice to be patient, a new version will be released real soon now (sic). It will not contain all the planned features but will allow for broader review of the new code by all interested parties. regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From paulha at aracnet.com Sat May 7 11:37:56 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Sat, 07 May 2005 08:37:56 -0700 Subject: [Nitro] [OG] - Code Repository (CVS / SVN), where? In-Reply-To: References: <427BDBE4.6050502@nasis.com> <427C209C.6040801@neurogami.com> Message-ID: <427CE0D4.2010900@aracnet.com> I'm just sorry it had to be done. George Moschovitis wrote: >Ok, I added moderation to his account. I 'll accept only his useful >messages and delete the excessive spam. Hope this helps to increase >the SNR. > >-g. > > > > >>>I think we'd all be happy if this one would shut up. >>> >>> >>I agree. He's made himself unwelcome on other lists, and I'm >>disappointed to see him here. I have his mail filtered straight to trash. >> >>I'd prefer folks simply ignore him. >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050507/e6026932/attachment.html From george.moschovitis at gmail.com Sat May 7 14:16:45 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sat, 7 May 2005 21:16:45 +0300 Subject: [Nitro] Schema evolution Message-ID: Hello all, I was thinking today a bit about schema evolution. I think these are the four cases: 1. a new property (== column) is added 2. an existing property is deleted 3. an existing property is renamed 4. the meta data (for example type) of an existing property is changed. 1-2: can be detected and solved automatically (Og will just ask for confirmation on the command line) 4. can be detected automatically. 3. some cases can be detected and resolved with a simple question to the user. Then of course there is the issue of changes in relations. Am I missing any other 'trivial' change? Anyway I plan to add an OO abstraction of the ALTER command, IE a mechanism for describing non-trivial schema changes. This way one could checkout the Og evolution code to the live server and just run the script to update the live schema. Any thoughts on this? regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From paulha at aracnet.com Sat May 7 15:47:11 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Sat, 07 May 2005 12:47:11 -0700 Subject: [Nitro] Schema evolution -- Semi-random wanderings... In-Reply-To: References: Message-ID: <427D1B3F.40006@aracnet.com> Re: questions to the user-- Don't think that is a good idea in a production environment. Perhaps it would make sense in a development environment... /From the perspective of the database schema:/ So far, we've only considered changes within a class that impact only that class. That is a relatively minor case, I think... Tables are often split and/or physically joined in various ways. It does not seem likely that we can provide an automatic way of accounting for this... /From the perspective of the class:/ Classes do sometimes get merged or split. So the case above probably is not spurious. Inheritance probably complicates these issues. /Danger: / There is a danger that joined tables will only be partially populated, or that fields split away from the source table will be empty (because they look like a new field or a new table). /An Idea.../ Part of the problem is correlating whether a field is new, or moved, and how it connects to the data with which it appears. How about (the programmer) assigning an optional universal identifier to each field and recording the field, identifier, source table, etc into a dictionary table. When an application starts up, it can check the old definition against the new. If all the fields of the database can be identified, it should be possible to semi-automatically migrate from the old DB to the new. The downside to this technique is that you really need to know all the class definitions at startup-- on-the-fly conversions would not be a good idea. A terrible idea-- a utility to read sources and anticipate the structure of the database, recording it, comparing it to the previous structure and writing a migration program which would be completed by the programmer. :-( Paul George Moschovitis wrote: >Hello all, > >I was thinking today a bit about schema evolution. I think these are >the four cases: > >1. a new property (== column) is added >2. an existing property is deleted >3. an existing property is renamed >4. the meta data (for example type) of an existing property is changed. > > >1-2: can be detected and solved automatically (Og will just ask for >confirmation on the command line) >4. can be detected automatically. >3. some cases can be detected and resolved with a simple question to the user. > >Then of course there is the issue of changes in relations. Am I >missing any other 'trivial' change? > >Anyway I plan to add an OO abstraction of the ALTER command, IE a >mechanism for describing non-trivial schema changes. This way one >could checkout the Og evolution code to the live server and just run >the script to update the live schema. > >Any thoughts on this? > >regards, >George. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050507/1788202c/attachment.html From Aleksi.Niemela at cs.helsinki.fi Sun May 8 08:18:57 2005 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Sun, 08 May 2005 15:18:57 +0300 Subject: [Nitro] Many_to_many delete_#{prop_o} +_only Message-ID: <427E03B1.9040000@cs.helsinki.fi> I didn't find Og repository or associated mailing list, so I ended up writing here. Please redirect me to correct place, although Mr. Moschovitis probably reads this one too. :) Consider class House many_to_many :on_street, Street end class Street many_to_many :houses, House end Now, most houses are only on one street but houses on street corners might have exits and addresses for both streets (among other special cases). If an exit is closed (door way is sealed), one's inclined to say: street_that_wont_have_exit_anymore = Street[x] house.delete_on_street(street_that_wont_have_exit_anymore) What happens is that no houses on that street will have exits to this street after previous code executes. What I expected is that only this single association for this (house, street) pair is affected. Thus, here's the patch for enchanting delete_prop_only() that I use privately. Have I understood incorrectly, should there be this additional version or is there a bug in normal enchanted delete_prop? - Aleksi $ diff -u meta.rb~ meta.rb --- meta.rb~ 2005-04-09 11:56:32.790039000 +0300 +++ meta.rb 2005-05-08 14:51:48.484375000 +0300 @@ -294,6 +294,10 @@ Og.db.exec("DELETE FROM #{Og::Adapter.join_table(self, klass, name)} WHERE key2=\#\{obj_ or_oid.to_i\}") end + def delete_#{prop_o}_only(obj_or_oid) + Og.db.exec("DELETE FROM #{Og::Adapter.join_table(self, klass, name)} WHERE key1=\#\@oid and key2=\#\{obj_or_oid.to_i\}") + end + def clear_#{list_o} Og.db.exec("DELETE FROM #{Og::Adapter.join_table(self, klass, name)} WHERE key1=\#\@oid" ) end From george.moschovitis at gmail.com Mon May 9 05:27:14 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 May 2005 12:27:14 +0300 Subject: [Nitro] Many_to_many delete_#{prop_o} +_only In-Reply-To: <427E03B1.9040000@cs.helsinki.fi> References: <427E03B1.9040000@cs.helsinki.fi> Message-ID: Hello Aleksi, On 5/8/05, Aleksi Niemela wrote: > I didn't find Og repository or associated mailing list, so I ended up > writing here. This is the correct mailing list for Og related questions. > What happens is that no houses on that street will have exits to this > street after previous code executes. What I expected is that only this > single association for this (house, street) pair is affected. Thus, > here's the patch for enchanting delete_prop_only() that I use privately. > Have I understood incorrectly, should there be this additional version > or is there a bug in normal enchanted delete_prop? I consider this a bug in the normal delete_prop. Thanks for the patch I 'll integrate this in the new version of Og I am working on. best regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From Aleksi.Niemela at cs.helsinki.fi Mon May 9 05:32:15 2005 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Mon, 09 May 2005 12:32:15 +0300 Subject: [Nitro] Many_to_many delete_#{prop_o} +_only In-Reply-To: References: <427E03B1.9040000@cs.helsinki.fi> Message-ID: <427F2E1F.9000204@cs.helsinki.fi> George Moschovitis wrote: >On 5/8/05, Aleksi Niemela wrote: > > >>What happens is that no houses on that street will have exits to this >>street after previous code executes. What I expected is that only this >>single association for this (house, street) pair is affected. Thus, >>here's the patch for enchanting delete_prop_only() that I use privately. >>Have I understood incorrectly, should there be this additional version >>or is there a bug in normal enchanted delete_prop? >> >> > >I consider this a bug in the normal delete_prop. Thanks for the patch >I 'll integrate this in the new version of Og I am working on. > > Please note that current version of delete_prop() is also useful, just like there's clear() for the other side of deleting bunch of pairs. What would be good name for that is beyond me. - Aleksi From george.moschovitis at gmail.com Mon May 9 05:51:01 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 9 May 2005 12:51:01 +0300 Subject: [Nitro] Many_to_many delete_#{prop_o} +_only In-Reply-To: <427F2E1F.9000204@cs.helsinki.fi> References: <427E03B1.9040000@cs.helsinki.fi> <427F2E1F.9000204@cs.helsinki.fi> Message-ID: Don't worry I 'll keep the full functionality. If there is anything else you think that should be changed/improved, let me know. regards, George. On 5/9/05, Aleksi Niemela wrote: > George Moschovitis wrote: > > >On 5/8/05, Aleksi Niemela wrote: > > > > > >>What happens is that no houses on that street will have exits to this > >>street after previous code executes. What I expected is that only this > >>single association for this (house, street) pair is affected. Thus, > >>here's the patch for enchanting delete_prop_only() that I use privately. > >>Have I understood incorrectly, should there be this additional version > >>or is there a bug in normal enchanted delete_prop? > >> > >> > > > >I consider this a bug in the normal delete_prop. Thanks for the patch > >I 'll integrate this in the new version of Og I am working on. > > > > > Please note that current version of delete_prop() is also useful, just > like there's clear() for the other side of deleting bunch of pairs. What > would be good name for that is beyond me. > > - Aleksi > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Wed May 11 10:50:11 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 11 May 2005 17:50:11 +0300 Subject: [Nitro] Og in revese engineering mode Message-ID: Hello all, I would like to add support for 'reverse engineering' an existing schema in the new version of Og. IE, you will be able to set primary key names, table names, property column names as needed to use an existing schema. If anyone would like to send me an example schema please feel free to email me privately. regards, George. PS: this feature will be probably delayed until 0.18.0 though, as I am real close to releasing the shinny new 0.17.0 now. 0.17.0 or 'Og Reloaded' will be the base for future releases. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Thu May 12 04:10:43 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 12 May 2005 11:10:43 +0300 Subject: [Nitro] Many to many Message-ID: Hello all, I would like to replace the 'many_to_many' macro of the current Og with a new 'joins_many' macro. This is more flexible as it allows you to implement a 'has_many' relation using a join table. If you want to implement a 'many_to_many' relation you just add 'joins_many' to both classes (the same join table is reused). Perhaps I can leave the 'many_to_many' macro as an alias. I am not sure this can be done, but I am wondering if anyone sees any problem with this, before I go on and implement this. thanks, George. -- http://nitro.rubyforge.org http://www.joy.gr From Aleksi.Niemela at cs.helsinki.fi Thu May 12 09:01:49 2005 From: Aleksi.Niemela at cs.helsinki.fi (Aleksi Niemela) Date: Thu, 12 May 2005 16:01:49 +0300 Subject: [Nitro] Many to many In-Reply-To: References: Message-ID: <428353BD.6080904@cs.helsinki.fi> George Moschovitis wrote: >Hello all, > >I would like to replace the 'many_to_many' macro of the current Og >with a new 'joins_many' macro. This is more flexible as it allows you >to implement a 'has_many' relation using a join table. If you want to > This is definitely good. If Comment is related to certain Article and ArticleCategory as well, Comment.belongs_to(Article) and Comment.belongs_to(ArticleCategory) hasn't been possible. Now table Comment can stay compact and there will be joining table for every different item that associates comments. I'm sure you meant that has_many will stay around, as it's still essential in case when there will be only one item (just Article, no ArticleCategory) that needs comments. IMO many_to_many is good name on conceptual level where as joins_many is quite a bit deeper, on the dbms-level of name. >I am not sure this can be done, but I am wondering if anyone sees any >problem with this, before I go on and implement this. > More complex you make Og easier it will be to do things by coding and manually altering database. But simultaneously it will be much more complex to make automatic database evolution for Og. Now, for example one needs to introduce at least following database level refactorings: - add clean joins_many - delete joins_many - change either of the classes that joins_many -table joins together (ie. Comment <-> Article --> ArticleComment <-> Article) - probably the most non-trivial, one has to do Comment -> ArticleComment mapping on class and object level, handle missing objects on both ends etc. - split has_many into joins_many (split object table into object table and join table, probably quite trivial) - combine joins_many into object table, probably trivial as well - unless there're joins without base object, ie. deleted Comment but not it's association to Article) - Aleksi From george.moschovitis at gmail.com Mon May 16 09:56:00 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 May 2005 16:56:00 +0300 Subject: [Nitro] Nitro + Og 0.17.0 Message-ID: New versions of Nitro + Og where released. For more information have a look here: http://rubyforge.org/forum/forum.php?forum_id=3067 Due to the many changes, this version is considered a preview, IE bugs are expected. You comments and bug reports are especially welcome. best regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From paulha at aracnet.com Mon May 16 11:03:21 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Mon, 16 May 2005 08:03:21 -0700 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: Message-ID: <4288B639.4040802@aracnet.com> The description is very impressive, George! Congratulations to your team! :-) You're going to force me to learn it all yet! ;-) Paul PS-- (Actually, I want to. It's a matter of attention span. O:-) ) George Moschovitis wrote: >New versions of Nitro + Og where released. For more information have a >look here: > >http://rubyforge.org/forum/forum.php?forum_id=3067 > >Due to the many changes, this version is considered a preview, IE bugs >are expected. You comments and bug reports are especially welcome. > > >best regards, >George. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050516/e58c9fa0/attachment.html From alang at cronosys.com Mon May 16 11:20:32 2005 From: alang at cronosys.com (Alan Garrison) Date: Mon, 16 May 2005 11:20:32 -0400 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: Message-ID: <4288BA40.4060008@cronosys.com> George Moschovitis wrote: >New versions of Nitro + Og where released. For more information have a >look here: > >http://rubyforge.org/forum/forum.php?forum_id=3067 > >Due to the many changes, this version is considered a preview, IE bugs >are expected. You comments and bug reports are especially welcome. > > >best regards, >George. > > > Quick question: Does this release obsolete some/any of the RubyGarden intro to Og? From george.moschovitis at gmail.com Mon May 16 11:52:46 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 May 2005 18:52:46 +0300 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <4288BA40.4060008@cronosys.com> References: <4288BA40.4060008@cronosys.com> Message-ID: > Quick question: Does this release obsolete some/any of the RubyGarden > intro to Og? The new version is mostly compatible with the tutorial. I suggest that you have a look at the file: test/og/tc_store.rb The api is slightly improved, typically removed SQL dependencies. regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From james_b at neurogami.com Mon May 16 12:52:11 2005 From: james_b at neurogami.com (James Britt) Date: Mon, 16 May 2005 09:52:11 -0700 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: <4288BA40.4060008@cronosys.com> Message-ID: <4288CFBB.1050604@neurogami.com> George Moschovitis wrote: >>Quick question: Does this release obsolete some/any of the RubyGarden >>intro to Og? > > > The new version is mostly compatible with the tutorial. I suggest that > you have a look at the file: > > test/og/tc_store.rb > > The api is slightly improved, typically removed SQL dependencies. I've still not found the time to do a proper evaluation of the new code (but I will!), but can you tell me if this means that one can (more or less) switch between, say, Kirbybase and MySQL? Thanks, James -- http://www.ruby-doc.org http://www.rubyxml.com http://catapult.rubyforge.org http://orbjson.rubyforge.org http://ooo4r.rubyforge.org http://www.jamesbritt.com From george.moschovitis at gmail.com Mon May 16 13:00:54 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 May 2005 20:00:54 +0300 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <4288CFBB.1050604@neurogami.com> References: <4288BA40.4060008@cronosys.com> <4288CFBB.1050604@neurogami.com> Message-ID: > I've still not found the time to do a proper evaluation of the new code > (but I will!), but can you tell me if this means that one can (more or > less) switch between, say, Kirbybase and MySQL? KirbyBase is not supported yet. But I 'll add support. However you can switch between Mysql and the Memory Store. After the switch you can use the same querying interface even with joins and relations. The memory store is very simple: Just a Hash of (class) Hashes. When the program begins the hash is read from a yaml find and when the program ends the hash is serialized as yaml to the file. It is relatively easy to convert this to a madeleine back end. BTW, now that the querying mechanism is SQL agnostic and the stores implementation much easier to write perhaps you could try to come up with a KirbyBase store. Alternatively, you can wait till I find some time to do this ;-) regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From james_b at neurogami.com Mon May 16 13:32:49 2005 From: james_b at neurogami.com (James Britt) Date: Mon, 16 May 2005 10:32:49 -0700 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: <4288BA40.4060008@cronosys.com> <4288CFBB.1050604@neurogami.com> Message-ID: <4288D941.7060200@neurogami.com> George Moschovitis wrote: >>I've still not found the time to do a proper evaluation of the new code >>(but I will!), but can you tell me if this means that one can (more or >>less) switch between, say, Kirbybase and MySQL? > > > KirbyBase is not supported yet. But I 'll add support. However you can > switch between Mysql and the Memory Store. After the switch you can > use the same querying interface even with joins and relations. The > memory store is very simple: Just a Hash of (class) Hashes. When the > program begins the hash is read from a yaml find and when the program > ends the hash is serialized as yaml to the file. It is relatively easy > to convert this to a madeleine back end. OK, thanks. I just Kirbybase as an example of a non-SQL storage engine. This sounds pretty sweet. Thanks, James -- http://www.ruby-doc.org http://www.rubyxml.com http://catapult.rubyforge.org http://orbjson.rubyforge.org http://ooo4r.rubyforge.org http://www.jamesbritt.com From jperrot at exosec.fr Mon May 16 14:45:59 2005 From: jperrot at exosec.fr (Julien Perrot) Date: Mon, 16 May 2005 20:45:59 +0200 Subject: [Nitro] Patch for Og 0.17.0 Message-ID: <200505162046.00293.jperrot@exosec.fr> I've just submitted a patch for Og 0.17.0 (great release by the way) : this patch fixes a few problems I have met with this release. http://rubyforge.org/tracker/index.php?func=detail&aid=1920&group_id=418&atid=1672 The most significant change is new semantics for the clear method of the Collection class (it's a fallback to the semantics of Og 0.16.0 in fact) : the clear methods does not delete the objects themselves, only the relations (in the join tables) between the members and the owner. Regards, Julien Perrot From george.moschovitis at gmail.com Mon May 16 16:30:37 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 16 May 2005 23:30:37 +0300 Subject: [Nitro] Patch for Og 0.17.0 In-Reply-To: <200505162046.00293.jperrot@exosec.fr> References: <200505162046.00293.jperrot@exosec.fr> Message-ID: Hello Julien, thanks for the patch! I planned to add a method 'unjoin' for the functionality you described, but I 'll have a look at your patch. Creating complex software like Og and Nitro is quite difficult. Help in the form of patches and ideas is really needed for this project to go on! I hope to hear more from you :) best regards, George. On 5/16/05, Julien Perrot wrote: > I've just submitted a patch for Og 0.17.0 (great release by the way) : this > patch fixes a few problems I have met with this release. > > http://rubyforge.org/tracker/index.php?func=detail&aid=1920&group_id=418&atid=1672 > > The most significant change is new semantics for the clear method of the > Collection class (it's a fallback to the semantics of Og 0.16.0 in fact) : > the clear methods does not delete the objects themselves, only the relations > (in the join tables) between the members and the owner. > > Regards, > Julien Perrot > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr From alang at cronosys.com Mon May 16 16:49:06 2005 From: alang at cronosys.com (Alan Garrison) Date: Mon, 16 May 2005 16:49:06 -0400 Subject: [Nitro] Og in revese engineering mode In-Reply-To: References: Message-ID: <42890742.4000202@cronosys.com> George Moschovitis wrote: >Hello all, > >I would like to add support for 'reverse engineering' an existing >schema in the new version of Og. IE, you will be able to set primary >key names, table names, property column names as needed to use an >existing schema. If anyone would like to send me an example schema >please feel free to email me privately. > >regards, >George. > >PS: this feature will be probably delayed until 0.18.0 though, as I am >real close to releasing the shinny new 0.17.0 now. 0.17.0 or 'Og >Reloaded' will be the base for future releases. > > > > How do you plan to implement this? By querying the ANSI "information schema" views for the DBs that support it? I'm going to need to implement something like this soon for a project I'm doing (though mine is postgres specific, so I may cheat and just query the pg_ tables). From james_b at neurogami.com Mon May 16 23:22:23 2005 From: james_b at neurogami.com (James Britt) Date: Mon, 16 May 2005 20:22:23 -0700 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: Message-ID: <4289636F.2010104@neurogami.com> George Moschovitis wrote: > New versions of Nitro + Og where released. For more information have a > look here: > > http://rubyforge.org/forum/forum.php?forum_id=3067 > > Due to the many changes, this version is considered a preview, IE bugs > are expected. You comments and bug reports are especially welcome. There's a bug in nitrogen on Windows (only place I've run it) in that it treats the ruby bin directory as the base dir. So, d:\foo> nitrogen myapp creates c:\ruby\bin\myapp with all the skeleton code. Running d:\foo> nitrogen ./myapp doesn't help. James > > > best regards, > George. > -- http://www.ruby-doc.org http://www.rubyxml.com http://catapult.rubyforge.org http://orbjson.rubyforge.org http://ooo4r.rubyforge.org http://www.jamesbritt.com From george.moschovitis at gmail.com Tue May 17 04:56:45 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 17 May 2005 11:56:45 +0300 Subject: [Nitro] 'Module' of functionality Message-ID: Hello all, I am trying to come up with a good name for a high level module of functionality. Let's say you are tying to build a high level framework on top of nitro. Example 'modules' may be: - forum - photos - users - content etc, etc... since Module is reserved by Ruby, I would like to hear some suggestions for alternatives. At the moment I am using 'part'. regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From alang at cronosys.com Tue May 17 08:47:53 2005 From: alang at cronosys.com (Alan Garrison) Date: Tue, 17 May 2005 08:47:53 -0400 Subject: [Nitro] 'Module' of functionality In-Reply-To: References: Message-ID: <4289E7F9.8070307@cronosys.com> George Moschovitis wrote: >Hello all, > >I am trying to come up with a good name for a high level module of >functionality. Let's say you are tying to build a high level framework >on top of nitro. Example 'modules' may be: > >- forum >- photos >- users >- content > >etc, etc... > >since Module is reserved by Ruby, I would like to hear some >suggestions for alternatives. >At the moment I am using 'part'. > >regards, >George. > > > My first thought is "applet". Are you planning something to write on "top" of Nitro? I'd love to see a ruby equivalent of the Horde project (www.horde.org), which is a PHP app framework with a number of plug-in apps available. The Horde framework level handles sessions, user auth, ACLs, templating, inter-app communication, etc. I know Nitro does some of this but, at least for my purposes, isn't a full app framework yet. Applet for Nitro = Nitrolet? Nitlet? :) From james_b at neurogami.com Tue May 17 10:18:28 2005 From: james_b at neurogami.com (James Britt) Date: Tue, 17 May 2005 07:18:28 -0700 Subject: [Nitro] 'Module' of functionality In-Reply-To: References: Message-ID: <4289FD34.8010501@neurogami.com> George Moschovitis wrote: > Hello all, > > I am trying to come up with a good name for a high level module of > functionality. Let's say you are tying to build a high level framework > on top of nitro. Example 'modules' may be: > > - forum > - photos > - users > - content > > etc, etc... > > since Module is reserved by Ruby, I would like to hear some > suggestions for alternatives. > At the moment I am using 'part'. Component Service Element Resource I'm partial to Service or Element, though some of these examples may be more high-level than that. I'd prefer to avoid copying terms from other languages (e.g. applet and it's variations) or frameworks if possible. Too much baggage. James From george.moschovitis at gmail.com Tue May 17 10:22:15 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 17 May 2005 17:22:15 +0300 Subject: [Nitro] 'Module' of functionality In-Reply-To: <4289FD34.8010501@neurogami.com> References: <4289FD34.8010501@neurogami.com> Message-ID: > Element Element is used for something else (something like JSP tag libraries): check out lib/nitro/element.rb it is under construction, but i used as an XSLT replacements for some projects I want to run under windows. I want something bigger than component, ie a 'module' may contain multiple 'components' -g. -- http://nitro.rubyforge.org http://www.joy.gr From paulha at aracnet.com Tue May 17 10:59:45 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Tue, 17 May 2005 07:59:45 -0700 Subject: [Nitro] 'Module' of functionality In-Reply-To: <4289E7F9.8070307@cronosys.com> References: <4289E7F9.8070307@cronosys.com> Message-ID: <428A06E1.9050905@aracnet.com> Molecule, Compound, Bond, Radical, Nitrous, Dynamite(!), Nitric, Nitrite, Nitrate. As an analog for module, Molecule, Nitrite, and Nitrate would have the best parallels. As a name for a technology, I like Dynamite! Paul Alan Garrison wrote: > George Moschovitis wrote: > >> Hello all, >> >> I am trying to come up with a good name for a high level module of >> functionality. Let's say you are tying to build a high level framework >> on top of nitro. Example 'modules' may be: >> >> - forum >> - photos >> - users >> - content >> >> etc, etc... >> >> since Module is reserved by Ruby, I would like to hear some >> suggestions for alternatives. >> At the moment I am using 'part'. >> >> regards, >> George. >> >> >> > My first thought is "applet". Are you planning something to write on > "top" of Nitro? I'd love to see a ruby equivalent of the Horde > project (www.horde.org), which is a PHP app framework with a number of > plug-in apps available. The Horde framework level handles sessions, > user auth, ACLs, templating, inter-app communication, etc. I know > Nitro does some of this but, at least for my purposes, isn't a full > app framework yet. > > Applet for Nitro = Nitrolet? Nitlet? :) > > _______________________________________________ > 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/20050517/11728708/attachment.html From george.moschovitis at gmail.com Tue May 17 11:07:24 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Tue, 17 May 2005 18:07:24 +0300 Subject: [Nitro] 'Module' of functionality In-Reply-To: <428A06E1.9050905@aracnet.com> References: <4289E7F9.8070307@cronosys.com> <428A06E1.9050905@aracnet.com> Message-ID: Hmm, i like Molecule, but i think Part is better (shorter). Currently, I am trying to make this a bit more neutral so perhaps a name is not needed. -g. -- http://nitro.rubyforge.org http://www.joy.gr From nospam at lunacymaze.org Tue May 17 17:53:47 2005 From: nospam at lunacymaze.org (Ghislain Mary) Date: Tue, 17 May 2005 23:53:47 +0200 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <4289636F.2010104@neurogami.com> References: <4289636F.2010104@neurogami.com> Message-ID: <428A67EB.7000309@lunacymaze.org> James Britt a ?crit : > There's a bug in nitrogen on Windows (only place I've run it) in that it > treats the ruby bin directory as the base dir. > > So, > > d:\foo> nitrogen myapp > > creates > > c:\ruby\bin\myapp > > with all the skeleton code. > > Running > > d:\foo> nitrogen ./myapp > Got the same problem on MacOS X Panther. Doing, > nitrogen myapp tries to create /usr/local/bin/myapp but fails since the user hasn't got the privileges to write there... Ghislain From slewis at orcon.net.nz Tue May 17 18:07:07 2005 From: slewis at orcon.net.nz (Stephen Lewis) Date: Wed, 18 May 2005 10:07:07 +1200 Subject: [Nitro] [Og] Simple suggestion for sqlite store Message-ID: <20050517220707.GA5459@ws0.localdomain> Hi I've just been experimenting with Og for a small project I'm playing with, and I have to say that so far it seems pretty cool (thanks!:) But, (there's always a but :) I have a small change to propose that would be quite convenient (for me, at least). The project is a desktop app, so it actually matters what filename is used for the data files (e.g. for extension handling, "file exists, do you wish to overwrite..." etc). I've attached a patch against Og-0.17.0 introduces a trivial option for sqlite stores, :sqlite_respect_name, which causes Og to use the store :name as the actual filename, without appending a ".db" suffix. If this way of doing it seems cumbersome, any alternative way would be appreciated - I imagine it might be a relevant option for file backed stores in general. Also, the dependency documentation doesn't seem to mention that sqlite3-ruby (>= 1.1.0) is required - I started out trying to get it working with 0.9.0 (the version in FreeBSD's ports tree atm), which is lacking some needed methods - it wasn't a big deal or anything, but it's handy to know :) Thanks, Stephen Lewis -------------- next part -------------- diff -ur og-0.17.0-orig/lib/og/store/sqlite.rb og-0.17.0/lib/og/store/sqlite.rb --- og-0.17.0-orig/lib/og/store/sqlite.rb Sun May 15 04:36:05 2005 +++ og-0.17.0/lib/og/store/sqlite.rb Wed May 18 09:25:15 2005 @@ -38,9 +38,17 @@ class SqliteStore < SqlStore + def self.filename(options) + if options[:sqlite_respect_name] + options[:name] + else + "#{options[:name]}.db" + end + end + def self.destroy(options) begin - FileUtils.rm("#{options[:name]}.db") + FileUtils.rm(SqliteStore.filename(options)) super rescue Object Logger.info "Cannot drop '#{options[:name]}'!" @@ -49,7 +57,7 @@ def initialize(options) super - @conn = SQLite3::Database.new("#{options[:name]}.db") + @conn = SQLite3::Database.new(SqliteStore.filename(options)) end def close From george.moschovitis at gmail.com Wed May 18 02:36:50 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 May 2005 09:36:50 +0300 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <428A67EB.7000309@lunacymaze.org> References: <4289636F.2010104@neurogami.com> <428A67EB.7000309@lunacymaze.org> Message-ID: Will fix. thanks for reporting... Btw, I have never tried Nitro/Og on MacOSX. Have you managed to run the nitro examples? regards, George On 5/18/05, Ghislain Mary wrote: > James Britt a ?crit : > > There's a bug in nitrogen on Windows (only place I've run it) in that it > > treats the ruby bin directory as the base dir. > > > > So, > > > > d:\foo> nitrogen myapp > > > > creates > > > > c:\ruby\bin\myapp > > > > with all the skeleton code. > > > > Running > > > > d:\foo> nitrogen ./myapp > > > > Got the same problem on MacOS X Panther. Doing, > > nitrogen myapp > tries to create /usr/local/bin/myapp but fails since the user hasn't got > the privileges to write there... > > Ghislain > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Wed May 18 02:47:21 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 May 2005 09:47:21 +0300 Subject: [Nitro] [Og] Simple suggestion for sqlite store In-Reply-To: <20050517220707.GA5459@ws0.localdomain> References: <20050517220707.GA5459@ws0.localdomain> Message-ID: > The project is a desktop app, so it actually matters what filename is > used for the data files (e.g. for extension handling, "file exists, do > you wish to overwrite..." etc). I've attached a patch against > Og-0.17.0 introduces a trivial option for sqlite stores, > :sqlite_respect_name, which causes Og to use the store :name as the > actual filename, without appending a ".db" suffix. An older version included an overridable method that returned the name of the file to be used. I 'll add this method to the new store. Thanks for reminding. > Also, the dependency documentation doesn't seem to mention that > sqlite3-ruby (>= 1.1.0) is required - I started out trying to get it > working with 0.9.0 (the version in FreeBSD's ports tree atm), which > is lacking some needed methods - it wasn't a big deal or anything, but > it's handy to know :) I 'll add the requirement in the docs. regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From nospam at lunacymaze.org Wed May 18 12:31:47 2005 From: nospam at lunacymaze.org (Ghislain Mary) Date: Wed, 18 May 2005 18:31:47 +0200 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: <4289636F.2010104@neurogami.com> <428A67EB.7000309@lunacymaze.org> Message-ID: <428B6DF3.9040402@lunacymaze.org> George Moschovitis a ?crit : > Will fix. > > thanks for reporting... Btw, I have never tried Nitro/Og on MacOSX. > Have you managed to run the nitro examples? > > regards, > George > It looks like a bug with the rubygems packaging. I will try the "normal" packaging and tell what the result is (I don't really like those gems things in fact...). I managed to run all the nitro examples except for the flash one. I don't know why it didn't work. I have ruby/ming installed and it seems to work so it doesn't look like it's coming from here. I will try again. I plan to take a closer look to nitro and og, and I'm using MacOS X right now. If I find anything which seems to not be right, be sure you'll have feedback ;-) Ghislain From george.moschovitis at gmail.com Wed May 18 13:44:38 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Wed, 18 May 2005 20:44:38 +0300 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <428B6DF3.9040402@lunacymaze.org> References: <4289636F.2010104@neurogami.com> <428A67EB.7000309@lunacymaze.org> <428B6DF3.9040402@lunacymaze.org> Message-ID: > It looks like a bug with the rubygems packaging. I will try the "normal" > ... > things in fact...). I 'll reimplemented the generator following some suggestions by james. But I still think there is a gems problem here. I 'll investigate this further. > I managed to run all the nitro examples except for the flash one. I > ... > to work so it doesn't look like it's coming from here. I will try again. Sounds greate, I can add a 'Mac OSX compatible' label then :) > I plan to take a closer look to nitro and og, and I'm using MacOS X > right now. If I find anything which seems to not be right, be sure > you'll have feedback ;-) Great :) -g. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Thu May 19 09:47:43 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 19 May 2005 16:47:43 +0300 Subject: [Nitro] Patch for Og 0.17.0 In-Reply-To: <200505162046.00293.jperrot@exosec.fr> References: <200505162046.00293.jperrot@exosec.fr> Message-ID: Julien, in your patch I see: lib/og/store/sql.rb @@ -559,6 +567,10 @@ end row = res.next + + if row.empty? then + return nil + end I think the real problem is the implementation of ResultSet.blank in the sqlite3 store. Have a look at: lib/og/store/sqlite.rb 16: def blank? 17: false 18: end Have a look at the implementation of blank? in lets say the psql adapter. Any idea how to fix this? regards, George. On 5/16/05, Julien Perrot wrote: > I've just submitted a patch for Og 0.17.0 (great release by the way) : this > patch fixes a few problems I have met with this release. > > http://rubyforge.org/tracker/index.php?func=detail&aid=1920&group_id=418&atid=1672 > > The most significant change is new semantics for the clear method of the > Collection class (it's a fallback to the semantics of Og 0.16.0 in fact) : > the clear methods does not delete the objects themselves, only the relations > (in the join tables) between the members and the owner. > > Regards, > Julien Perrot > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr From jperrot at exosec.fr Thu May 19 12:17:02 2005 From: jperrot at exosec.fr (Julien Perrot) Date: Thu, 19 May 2005 18:17:02 +0200 Subject: [Nitro] Patch for Og 0.17.0 In-Reply-To: References: <200505162046.00293.jperrot@exosec.fr> Message-ID: <200505191817.03584.jperrot@exosec.fr> Le Jeudi 19 Mai 2005 15:47, George Moschovitis a ?crit?: > Julien, > > in your patch I see: > > lib/og/store/sql.rb > > @@ -559,6 +567,10 @@ > end > > row = res.next > + > + if row.empty? then > + return nil > + end > > I think the real problem is the implementation of ResultSet.blank in the > sqlite3 store. Have a look at: > > lib/og/store/sqlite.rb > > 16: def blank? > 17: false > 18: end > > Have a look at the implementation of blank? in lets say the psql > adapter. Any idea how to fix this? > > regards, > George. You're right : the method blank? in sqlite.rb is the one to be fixed. You can use the method eof? of the SQLite::ResultSet class (http://sqlite-ruby.rubyforge.org/classes/SQLite/ResultSet.html#M000063) to test if the result set is empty or not. I think this should fix this problem. Regards, Julien Perrot From nospam at lunacymaze.org Thu May 19 17:42:27 2005 From: nospam at lunacymaze.org (Ghislain Mary) Date: Thu, 19 May 2005 23:42:27 +0200 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: References: <4289636F.2010104@neurogami.com> <428A67EB.7000309@lunacymaze.org> <428B6DF3.9040402@lunacymaze.org> Message-ID: <428D0843.6010003@lunacymaze.org> Hi George, So, I tried the tar.gz distribution, and came back to the gems' one. Your install.rb script does not copy all the required files, and try to copy files which does not exist. For example, for og and nitro it tries to copy the directory vendor/ which is not there, so it fails. For nitro, the binaries nitro and nitrogen are not copied. BTW, once copied by hand, there's still the same error as with the gem distribution when using the nitrogen command. Concerning the flash example, I got a problem with ming so I can not really try it. But it looks like there's already a problem since the index page is not found. Either the root/ directory should be names public/ or the public_root should be defined. HTH Ghislain From george.moschovitis at gmail.com Fri May 20 04:59:40 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 May 2005 11:59:40 +0300 Subject: [Nitro] Nitro + Og 0.17.0 In-Reply-To: <428D0843.6010003@lunacymaze.org> References: <4289636F.2010104@neurogami.com> <428A67EB.7000309@lunacymaze.org> <428B6DF3.9040402@lunacymaze.org> <428D0843.6010003@lunacymaze.org> Message-ID: > Concerning the flash example, I got a problem with ming so I can not > ... > public/ or the public_root should be defined. Ok fixed it, thanks. -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Fri May 20 05:12:10 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Fri, 20 May 2005 12:12:10 +0300 Subject: [Nitro] Patch for Og 0.17.0 In-Reply-To: <200505191817.03584.jperrot@exosec.fr> References: <200505162046.00293.jperrot@exosec.fr> <200505191817.03584.jperrot@exosec.fr> Message-ID: Hello Jullien, > You're right : the method blank? in sqlite.rb is the one to be fixed. You can > use the method eof? of the SQLite::ResultSet class ok, that did the trick :) Since you are working with the sqlite store, here is another problem. In lib/og/store/sqlite.rb, try to uncomment this line: def close # FIXME: problems when closing due to unfinalised statements. # @conn.close super end And run the tests, any idea how to fix this? thanks for your help, -g. > (http://sqlite-ruby.rubyforge.org/classes/SQLite/ResultSet.html#M000063) to > test if the result set is empty or not. I think this should fix this problem. > > Regards, > Julien Perrot > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr From george.moschovitis at gmail.com Sun May 22 05:28:00 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Sun, 22 May 2005 12:28:00 +0300 Subject: [Nitro] Another name for controller Message-ID: Hello everyone, As I have said many times before, I don't like the name Controller that much. I find this too long. I am thinking about renaming controller to just Control. I would like to hear the list's opinion on this (or other suggestions). regards, George. -- http://nitro.rubyforge.org http://www.joy.gr From paulha at aracnet.com Sun May 22 16:48:45 2005 From: paulha at aracnet.com (PAUL HANCHETT) Date: Sun, 22 May 2005 13:48:45 -0700 Subject: [Nitro] Another name for controller In-Reply-To: References: Message-ID: <4290F02D.2060308@aracnet.com> Just a comment George-- Use industry accepted names for common patterns. Makes it much easier to work with. George Moschovitis wrote: >Hello everyone, > >As I have said many times before, I don't like the name Controller >that much. I find this >too long. I am thinking about renaming controller to just Control. I >would like to hear the >list's opinion on this (or other suggestions). > >regards, >George. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/nitro-general/attachments/20050522/303f3225/attachment.html From james_b at neurogami.com Sun May 22 19:17:26 2005 From: james_b at neurogami.com (James Britt) Date: Sun, 22 May 2005 16:17:26 -0700 Subject: [Nitro] Another name for controller In-Reply-To: References: Message-ID: <42911305.1000400@neurogami.com> George Moschovitis wrote: > Hello everyone, > > As I have said many times before, I don't like the name Controller > that much. I find this > too long. I am thinking about renaming controller to just Control. I > would like to hear the > list's opinion on this (or other suggestions). 'Controller' is more clear, more descriptive, than 'Control'. Go for the extra 3 letter, for the sake of clarity. James -- http://www.ruby-doc.org - The Ruby Documentation Site http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys From george.moschovitis at gmail.com Mon May 23 04:02:02 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Mon, 23 May 2005 11:02:02 +0300 Subject: [Nitro] Another name for controller In-Reply-To: <42911305.1000400@neurogami.com> References: <42911305.1000400@neurogami.com> Message-ID: > 'Controller' is more clear, more descriptive, than 'Control'. Go for the > extra 3 letter, for the sake of clarity. OK let's stick with Controller. -g. PS: even though I think the original MVC acronym stands for model-view-control, perhaps I am wrong. -- http://nitro.rubyforge.org http://www.joy.gr From james_b at neurogami.com Mon May 23 10:32:06 2005 From: james_b at neurogami.com (James Britt) Date: Mon, 23 May 2005 07:32:06 -0700 Subject: [Nitro] Another name for controller In-Reply-To: References: <42911305.1000400@neurogami.com> Message-ID: <4291E966.7070805@neurogami.com> George Moschovitis wrote: >>'Controller' is more clear, more descriptive, than 'Control'. Go for the >>extra 3 letter, for the sake of clarity. > > > OK let's stick with Controller. > > -g. > > PS: even though I think the original MVC acronym stands for > model-view-control, perhaps I am wrong. > http://c2.com/cgi/wiki?ModelViewControllerHistory James -- http://www.ruby-doc.org - The Ruby Documentation Site http://www.rubyxml.com - News, Articles, and Listings for Ruby & XML http://www.rubystuff.com - The Ruby Store for Ruby Stuff http://www.jamesbritt.com - Playing with Better Toys From steve at lumos.us Wed May 25 14:44:29 2005 From: steve at lumos.us (steve at lumos.us) Date: 25 May 2005 11:44:29 -0700 Subject: [Nitro] Oracle missing? Message-ID: <8664x74036.fsf@bitty.lumos.us> Oracle support seems to be missing from og-0.17.0. Is it possible to get it somewhere? Steve From george.moschovitis at gmail.com Thu May 26 02:30:56 2005 From: george.moschovitis at gmail.com (George Moschovitis) Date: Thu, 26 May 2005 09:30:56 +0300 Subject: [Nitro] Oracle missing? In-Reply-To: <8664x74036.fsf@bitty.lumos.us> References: <8664x74036.fsf@bitty.lumos.us> Message-ID: Hello Steve, I have not converted the 0.16.0 oracle driver to the new 0.17.0 interface. I could do this over the weekend and send it to you so that you can test this (I don't have access to an oracle db at the moment). Perhaps we can get this included in next week's 0.18.0 release. regards, -g. On 25 May 2005 11:44:29 -0700, steve at lumos.us wrote: > > Oracle support seems to be missing from og-0.17.0. Is it possible to > get it somewhere? > > Steve > > > _______________________________________________ > Nitro-general mailing list > Nitro-general at rubyforge.org > http://rubyforge.org/mailman/listinfo/nitro-general > -- http://nitro.rubyforge.org http://www.joy.gr