Hi all,
I''ve just uploaded to RubyForge a what seems to be usable version of
Instiki-AR (that''s Instiki with an ActiveRecord backend).
Unlike Instiki 0.10, this one is a normal Rails application, which means
you can host it on Apache, no more ProxyPass and Madeleine madness.
Download link:
http://rubyforge.org/frs/download.php/6251/instiki-ar-beta1.zip
As a beta version, it comes with some bugs and no documentation. If you
need a manual to install a Rails app, this release is not for you anyway :)
However, here is how to create a database and import data from Instiki
0.10 into it:
1. Copy config/database.default.yml to config/database.yml and edit it
2. If your database is MySQL, create an empty instance, and a user with
grants to that instance
3. Run ''ruby script/create_db''. This script creates database
objects in
all three schemas (test, development, production). Note that it fails if
an instance is not empty.
4. Run ''ruby script/import_storage -h'' for command line
options this
script understands. Here is how I run it:
ruby script\import_storage -i c:\instiki -t c:\instiki\storage\2500
-o i.sql -d mysql
5. Open a console to your production (or development) database and
execute i.sql in it.
Databases that I tried it on are SQLite and MySQL.
I am very much interested in bug reports and patches. The areas that are
expected to be bug-prone are page caching, admin interface, All Pages,
Apache/FCGI deployment and performance (although you need to have more
than a thousand revisions in your wiki before it starts to hurt in some
places).
Kudos are due to Rick Olson aka technoweenie for doing most of the
initial porting effort.
Best regards,
Alexey Verkhovsky
Hi Alexey, I get a 404 not found.. Ettore Il giorno 28/set/05, alle ore 06:55, Alexey Verkhovsky ha scritto:> Hi all, > > I''ve just uploaded to RubyForge a what seems to be usable version > of Instiki-AR (that''s Instiki with an ActiveRecord backend). > Unlike Instiki 0.10, this one is a normal Rails application, which > means you can host it on Apache, no more ProxyPass and Madeleine > madness. > > Download link: http://rubyforge.org/frs/download.php/6251/instiki- > ar-beta1.zip > > As a beta version, it comes with some bugs and no documentation. If > you need a manual to install a Rails app, this release is not for > you anyway :) > However, here is how to create a database and import data from > Instiki 0.10 into it: > > 1. Copy config/database.default.yml to config/database.yml and edit it > 2. If your database is MySQL, create an empty instance, and a user > with grants to that instance > 3. Run ''ruby script/create_db''. This script creates database > objects in all three schemas (test, development, production). Note > that it fails if an instance is not empty. > 4. Run ''ruby script/import_storage -h'' for command line options > this script understands. Here is how I run it: > ruby script\import_storage -i c:\instiki -t c:\instiki\storage > \2500 -o i.sql -d mysql > 5. Open a console to your production (or development) database and > execute i.sql in it. > > Databases that I tried it on are SQLite and MySQL. > > I am very much interested in bug reports and patches. The areas > that are expected to be bug-prone are page caching, admin > interface, All Pages, Apache/FCGI deployment and performance > (although you need to have more than a thousand revisions in your > wiki before it starts to hurt in some places). > > Kudos are due to Rick Olson aka technoweenie for doing most of the > initial porting effort. > > Best regards, > Alexey Verkhovsky > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Ettore wrote:> I get a 404 not found..Indeed. Seeing as it''s from different mirror all the time, this must have something to do with propagating the file to mirrors. Yikes... Anyway, you can get Instiki-AR from Subversion: svn co -r 397 http://svn.instiki.org/instiki/branches/instiki-ar This will get you the revision corresponding to the released file. Alex
Il giorno 28/set/05, alle ore 06:55, Alexey Verkhovsky ha scritto:> I''ve just uploaded to RubyForge a what seems to be usable version of > Instiki-AR (that''s Instiki with an ActiveRecord backend). > Unlike Instiki 0.10, this one is a normal Rails application, which > means you can host it on Apache, no more ProxyPass and Madeleine madness.Although I can easily imagine reasons for wanting to use ActiveRecord under Instiki, I''m curious about your ''madness'' characterization. Can you give a summary of your objections to these technologies? -r -- email: rdm-go8te9J4rpw@public.gmane.org; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
On Wed, Sep 28, 2005, Rich Morin wrote:> Il giorno 28/set/05, alle ore 06:55, Alexey Verkhovsky ha scritto: > > I''ve just uploaded to RubyForge a what seems to be usable version of > > Instiki-AR (that''s Instiki with an ActiveRecord backend). > > Unlike Instiki 0.10, this one is a normal Rails application, which > > means you can host it on Apache, no more ProxyPass and Madeleine madness. > > Although I can easily imagine reasons for wanting to use ActiveRecord > under Instiki, I''m curious about your ''madness'' characterization. Can > you give a summary of your objections to these technologies?I believe that the madness comment was primarily related to Madeleine. While Madeleine is great at what it does, it''s proven itself to be incapable of keeping up with large/heavily-trafficed wikis. The RoR wiki would be a prime example. Other people know more and I''m sure they''ll chime in, but one of the biggest problems is that Madeleine holds the entire database in memory, all the time. For wikis the size of the RoR wiki, with hundreds of pages and thousands of revisions, this gets unwieldy quickly. Running under WEBrick/Madeleine has also been quite unstable for a number of people. For instance, my local user group (the PDX Ruby Brigade) has been having problems with its instiki for months. It would just up and die for no particular reason. In short: madeleine is good for some things, not so good for huge wikis. Ben
Ben Bleything wrote:>On Wed, Sep 28, 2005, Rich Morin wrote: > > >>I''m curious about your ''madness'' characterization. Can >>you give a summary of your objections to these technologies? >> >> >I believe that the madness comment was primarily related to Madeleine. >While Madeleine is great at what it does, it''s proven itself to be >incapable of keeping up with large/heavily-trafficed wikis. >Just like the previous orator says, I have no objection to either technology, but to how they look in a web application. Basically, Madeleine means that (a) there is only one process (b) you cannot host it as FCGI (c) you need ProxyPass to host it as a web site Too much operational overhead comes with all this. As a developer, I also had problems with Madeleine''s conceptual overhead. This is what I wrote a few weeks ago to Martin Fowler, on a related subject: QTE Madeleine is bad because of: 1. Data compatibility (or migration) between versions. By far the biggest problem. Essentially, your data model is locked at the first release, just the same as with SQL backends. Except there is no explicit definition of the schema anywere in the code. There is no way to ''diff branches/release-1.0/db/schema.sql trunk/db/schema.sql'', either. 2. Since there is no schema and no integrity constraints, persistence problems tend to be much more subtle. Data migration defects are particularly evil, as they escape unit testing altogether. 3. It is ridiculously hard for a wiki admin to query persisted data, and practically impossible to change it in any non-trivial way. Doing it requires fairly profound understanding of Ruby, Madeleine and the application itself. There are several thousand Instiki users, but only 2 or 3 of them ever dared to tinker with storages, as far as I know. 4. Any data migration has to deal with two versions of the same class. It''s not impossible, but very complicated, compared with a bunch of ALTER TABLE Foo ADD Bar VARCHAR(20) statements. 5. Bugs and missing features in Madeleine. 6. My own lack of experience with this kind of persistence. There are no books about it, so trial, error and intensive head scratching were the only way to understand many things that now seem obvious to me. It was fun, educational, created eureka! experiences all the time, but my project velocity and quality suffered badly from it. All in all, almost all the downsides of a relational DB, no development velocity gained, and a big hit in maintenance costs. I can imagine situations where this sort of persistence would be a good fit, but a small wiki app just isn''t one of them. I wonder if the answer is as you suspected it will be? [Martin''s answer was "yes"] By the way, here is a counter-example in which prevaylence solves a real problem. I participated in a couple of large telecom projects, where we did soft-realtime billing of prepaid phone calls. That meant ~1000 incoming transactions/sec, each consisting of 5-10 selects, 3-5 inserts/updates and some business logic in between. A normal database wouldn''t handle it (not on a reasonably sized hardware), and the solution was to keep the data in RAM, using an RDBMS called TimesTen. This DB uses Prevayler-style persistence behind the curtains, but looks like a normal database to programmers and admins. So, all the tables are in memory, SELECTs never do any I/O at all, UPDATEs etc are logged as commands and you have a choice between hard commit (that flushes I/O buffers) or soft one (that doesn''t, which is much faster). In retrospective, this was a good practical compromise. You get the performance benefits (TimesTen alludes to something like "Oracle performance x 10"), but customer''s DBAs and Data Warehouse people can still do their job utilising their SQL knowledge. UNQTE Alex
Thanks to Ben and Alexey for clearing this up. I now have a much better appreciation for the pluses and minuses of Madeleine, etc. Given that I''m a Rails newby, I suspect that I would be wisest to avoid the first Beta. Do you have some idea of how fast this is likely to work its way through Beta? Also, would it be reasonable for the AR code to simply be folded into the main trunk, so that a developer could simply make a choice as to which back end to use? -r -- email: rdm-go8te9J4rpw@public.gmane.org; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
Great work to everyone on their effort on Instiki-AR. Quick question (just for the sake of curiousity) - are there any plans to include any wiki-spam counter-measures? I''m not sure what those counter-measures might be, but with wiki spam being such a problem I wasn''t sure if there were any clever solutions that we might see in Instiki-AR 1.0. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Daryl Richter
2005-Sep-29 21:03 UTC
[Instiki] [OT} Is the ruby-talk mailing list not working?
Has anyone else stopped getting any mail?
--
Daryl
"We want great men who, when fortune frowns, will not be discouraged."
-- Colonel Henry Knox, 1776
Rich Morin
2005-Sep-29 21:08 UTC
[Instiki] [OT} Is the ruby-talk mailing list not working?
Delivered-To: ruby-talk at ruby-lang.org Date: Fri, 30 Sep 2005 02:26:53 +0900 Posted: Thu, 29 Sep 2005 12:26:34 -0500 No, as of half an hour ago... -r At 5:03 PM -0400 9/29/05, Daryl Richter wrote:>Has anyone else stopped getting any mail? > >-- >Daryl > >"We want great men who, when fortune frowns, will not be discouraged." > -- Colonel Henry Knox, 1776 > >_______________________________________________ >Instiki-users mailing list >Instiki-users at rubyforge.org >http://rubyforge.org/mailman/listinfo/instiki-users-- email: rdm at cfcl.com; phone: +1 650-873-7841 http://www.cfcl.com - Canta Forda Computer Laboratory http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
Belorion wrote:> Quick question (just for the sake of curiousity) - are there any plans > to include any wiki-spam counter-measures?There is some in the trunk (as you might have noticed, we didn;t have too much of a spam problem on Instiki.org lately). I will merge these into the AR branch. Alex