Instiki users - Sep 2005 - ANN: Instiki-AR beta 1

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

Has anyone else stopped getting any mail?

-- 
Daryl

"We want great men who, when fortune frowns, will not be discouraged."
     -- Colonel Henry Knox, 1776

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