MagLev 1.0.0

[Monty Williams]

As you probably have seen, MagLev 1.0.0 was released early this
week. We also have a new website at http://maglev.github.com/

We've moved Ruby and Smalltalk source code that used to be internal
to the MagLev GitHub repository. This enables end users to modify
and build new versions of MagLev themselves. Since the installation
process now builds MagLev rather than downloading a pre-built version
we no longer need a different version for each platform.

MagLev includes RubyGems 1.8.11, Bundler 1.0.21, Rake 0.9.2, and
supports Sinatra 1.3.1 and Rails 3.1.1. For a more complete list
of changes, visit http://t.co/SHJTLqYv.

MagLev would not have been possible without much hard work by Allen
Otis, Peter McLain, Tim Felgentreff and others. We never would have
made it to 1.0 if it weren't for RubySpecs -- thanks esp. to Brian
Ford & the Rubinius team at EngineYard!

-- Monty

[Conrad Taylor]

Monty, this is great news indeed because I was thinking about Maglev the other day and I was going to post here.  Maglev just comes to mind anytime there's a discussion about data-stores.  Anyways, I read  the good news on the GS/SS Beta mailing list.

Well, I must go and I look forward to taking it for a spend.  Also, I need to make sure that my online example still works.

Thanks again for the awesome update,

-Conrad

 

--
You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
To post to this group, send email to maglev-d...@googlegroups.com.
To unsubscribe from this group, send email to maglev-discuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maglev-discussion?hl=en.

[Jupiter Jones]

Congratulations Monty and the Team!

Do you have an up-to-date GemTools?

Thanks for all the hard work.

[Michael Latta]

Great news. Any estimate for maglev in the cloud foundry open source? Chef script install?

Michael

[Josh Susser]

Very cool. Been a long time coming! Congratulations. Especially the
Rails 3.1 support, that's pretty big.

Any idea when the rvm installer will be operational? And when can we
expect some benchmarks?

--
Josh Susser
http://blog.hasmanythrough.com

[Conrad Taylor]

Sent from my iPhone

On Nov 5, 2011, at 1:57 PM, Josh Susser <jo...@hasmanythrough.com> wrote:

> Very cool. Been a long time coming! Congratulations. Especially the
> Rails 3.1 support, that's pretty big.
>
> Any idea when the rvm installer will be operational? And when can we
> expect some benchmarks?

Josh, I was able to install the latest by doing the following:

rvm install maglev-head

-Conrad

[Josh Susser]

Sweet, that did it.

--
Josh Susser
http://blog.hasmanythrough.com

[Jesse Cooke]

I've had a pull request in to ruby-build for a while, so hopefully soon that'll get accepted & MagLev 1.0.0 will be available to those using rbenv.

--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke

[Charles Monteiro]

sorry for being so out of the loop, so MagLev supports Rails 3.1.1 does that mean that that MagLev handles persistency i.e. I don't need to configure an RDMS , do all the ActiveRecords hooks work i.e. can I still use the standard relationship attributes 

Charles A. Monteiro
www.monteirosfusion.com
sent from the road

[Jesse Cooke]

MagLev can handle persistence, so no, you don't need any other database. But AFAIK there is no AR-like library out there besides my project, Tesla, based on @ecin's work from a while back.

Regardless, you wouldn't use the AR relationship references like has_many/belongs_to. You'd just stick the referenced objects into a collection on your model.

It's late, but see the gist I just whipped up* to get an idea of how this might work.

* Might not work exactly like that, but it's close ;-)

--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke

[Tim Felgentreff]

We thought about creating an ActiveModel adapter, but haven't gotten
around to do it before release. It shouldn't be too hard (the AM API
isn't very large, iirc), and if anybody is up to it we'd be glad to
provide help :)

[Conrad Taylor]

On Sat, Nov 5, 2011 at 8:46 PM, Charles Monteiro <cha...@monteirosfusion.com> wrote:

sorry for being so out of the loop, so MagLev supports Rails 3.1.1 does that mean that that MagLev handles persistency i.e. I don't need to configure an RDMS , do all the ActiveRecords hooks work i.e. can I still use the standard relationship attributes 

Charles, you have two choices:

a)  use the built in object persistence

    In this case, you wouldn't have to think in terns of OO being that you're using an OODBMS.  Thus, you'll be working with Ruby

   objects instead of relational table relationships like belongs_to, has_one, and has_many as defined in Rails.  In any case, I have

   put together a small example where you can see here:

   http://www.conradtaylor.com/2011/07/12/playing-with-maglev-the-ruby-vm

   AFAIK, there's no drop in replacement for Rails which allows one to use Maglev persistence.  However, if anyone is interested in

   taking on such a project, Yehuda Katz and Aaron Patterson recommended the following approach:

a)  create a connection adapter.  e.g. see sqlite3_adapter in Rails 3

https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb

b)  create a visitor e.g.  Rails out of the box supports the following visitors:

http://rubydoc.info/github/rails/arel/master/Arel/Visitors

https://github.com/rails/arel/tree/master/lib/arel/visitors

   

b) use a relational database system like MySQL, SQLite, Postgres, and so

    In this case, you'll be simply using Maglev for your Ruby implementation and using RDMS for your persistence.  Thus, you'll

    be able to use relational table relationships like belongs_to, has_one, and has_many as defined in Rails.  That is you'll be able

    to use the standard ActiveRecord constructs that you're familiar with in Rails.

c) use other NoSQL solutions like Riak, Redis, and so on

    In this case, you'll need to follow their respective instructions for integrating with your application.

[Conrad Taylor]

On Sun, Nov 6, 2011 at 7:46 AM, Conrad Taylor <conr...@gmail.com> wrote:

On Sat, Nov 5, 2011 at 8:46 PM, Charles Monteiro <cha...@monteirosfusion.com> wrote:

sorry for being so out of the loop, so MagLev supports Rails 3.1.1 does that mean that that MagLev handles persistency i.e. I don't need to configure an RDMS , do all the ActiveRecords hooks work i.e. can I still use the standard relationship attributes 

Charles, you have two choices:

a)  use the built in object persistence

    In this case, you wouldn't have to think in terns of OO being that you're using an OODBMS.  Thus, you'll be working with Ruby

   objects instead of relational table relationships like belongs_to, has_one, and has_many as defined in Rails.  In any case, I have

   put together a small example where you can see here:

   http://www.conradtaylor.com/2011/07/12/playing-with-maglev-the-ruby-vm

   AFAIK, there's no drop in replacement for Rails which allows one to use Maglev persistence.  However, if anyone is interested in

   taking on such a project, Yehuda Katz and Aaron Patterson recommended the following approach:

   1)  create a connection adapter.  e.g. see sqlite3_adapter in Rails 3

        https://github.com/rails/rails/blob/master/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb

   2)  create a visitor e.g.  Rails out of the box supports the following visitors:

        http://rubydoc.info/github/rails/arel/master/Arel/Visitors

        https://github.com/rails/arel/tree/master/lib/arel/visitors

   

b) use a relational database system like MySQL, SQLite, Postgres, and so

    In this case, you'll be simply using Maglev for your Ruby implementation and using RDMS for your persistence.  Thus, you'll

    be able to use relational table relationships like belongs_to, has_one, and has_many as defined in Rails.  That is you'll be able

    to use the standard ActiveRecord constructs that you're familiar with in Rails.

c) use other NoSQL solutions like Riak, Redis, and so on

    In this case, you'll need to follow their respective instructions for integrating with your application.

Well, I wish that the above helps and please post if you have further questions.

Good luck,

-Conrad

[Josh Susser]

ActiveModel wasn't built in a way that you can just mix it in and
support the API. And there are a few holes where it relies on methods
in ActiveRecord. But it's pretty small so it shouldn't be too hard to
build something like an ActiveObject module that can be mixed into
model classes.

I have done this with a subset of the API to support using plain
objects in Rails form helpers - that should at least be a good
starting point. See the informal gem:
https://github.com/joshsusser/informal

I'm interested in pushing forward on this front, but don't know how
much time I'll have to work on it soon.

--
Josh Susser
http://blog.hasmanythrough.com

[Jesse Cooke]

On Sun, Nov 6, 2011 at 11:20 AM, Josh Susser <jo...@hasmanythrough.com> wrote:

ActiveModel wasn't built in a way that you can just mix it in and
support the API. And there are a few holes where it relies on methods
in ActiveRecord. But it's pretty small so it shouldn't be too hard to
build something like an ActiveObject module that can be mixed into
model classes.

I thought that was exactly the purpose of ActiveModel?

Isn't that what the Lint Tests are for? I see you're using the lint tests in Informal. Were there things you ran into that prevented you from making Informal 100% compliant?

[Josh Susser]

On Sun, Nov 6, 2011 at 11:36 AM, Jesse Cooke <je...@jc00ke.com> wrote:
> On Sun, Nov 6, 2011 at 11:20 AM, Josh Susser <jo...@hasmanythrough.com>
> wrote:
>>
>> ActiveModel wasn't built in a way that you can just mix it in and
>> support the API. And there are a few holes where it relies on methods
>> in ActiveRecord. But it's pretty small so it shouldn't be too hard to
>> build something like an ActiveObject module that can be mixed into
>> model classes.
>
> I thought that was exactly the purpose of ActiveModel?

If you look at how ActiveRecord::Base works, it includes and extends
about a dozen separate modules from ActiveModel. That allows for some
flexibility in using AM, but it means there's no single thing to
include or inherit from.

> Isn't that what the Lint Tests are for? I see you're using the lint tests in
> Informal. Were there things you ran into that prevented you from making
> Informal 100% compliant?

The goal of Informal was not 100% AM compliance; it was to do the
simplest thing that would allow non-AR objects to be used in form
helpers. That means naming and validations - the rest is ignorable for
form helper support.

To support the full AM API shouldn't be too tricky, but that will
require figuring out how to map AM/AR semantics onto Maglev's object
persistence. I expect lifecycle callbacks will be the most difficult
to map, though it might be easier than I'm fearing. I also wonder if
there is a use for the formalism around attributes and associations -
the ability to reflect on those things makes it possible to use
metaprogramming to build tools like RailsAdmin. Maybe associations can
be useful for building scopes and doing eager loading - I'm not up to
speed yet on how those things work in Maglev.

[Jesse Cooke]

That brings up a good point: Should we want to map AM/AR semantics onto MagLev's persistence?

Is that the right thing to do?

My initial thought is that it's not, entirely. I suppose that's the raison d'etre for projects like Veneer.

How is this handled in Seaside or other Smalltalk projects?

[Monty Williams]

Hi Josh,

Thanks to @mpapis we got MagLe working under rvm on Friday. To install:
rvm get head; rvm install maglev; rvm use maglev

I hadn't run benchmarks in quite a while, so I did a quick run of the
same RBS benchmarks I used to run. There were no real differences.

I put the results from my iMac at home and my Ubuntu desktop at work
plus a snapshot of the benchmarks I ran on:
http://glass-downloads.gemstone.com/maglev/
RBS-MagLev1.0.0-MacOSX-111103.xls
RBS-MagLev1.0.0-Linux-111102.xls
RBS-snapshot.zip

There are no benchmarks incorporating MagLev persistence. Synthetic
benchmarks are not real useful in predicting application performance.

-- Monty

[Monty Williams]

I just built a new GemTools with the latest libraries, and updated it to GemTools 1.0-beta.8.5.
It's at http://seaside.gemstone.com/squeak/GemTools-MagLev-1.0.0.zip

Give it a try and let mw know if anything is broken.

-- Monty

--

[Charles Monteiro]

Conrad:

thanks , and thanks to all who continued the thread. Honestly, I'm not married to using ActiveRecord, I'm more concerned about what I need to remember and what I need to forget :)

Frankly, I"m more used to the Gemstone/ S model i.e. i.e. there's only one persisted object model based on roots. Is there the concept of some some root collection that I can iterate over ? Are there replication specs that control how object graphs are faulted to a client space ? Are there transaction blocks.

Probably the best question is this all documented somewhere. The MagLev site does not seem to have a listing of what the persistence API is.

thanks

-charles