Merb and 0.10RC1 not working together
Andy Shipman
Martin Gamsjaeger
Did you try my fork of merb?
http://github.com/snusnu/merb
From your original message I don't know if you just read my post, or
if you actually tried it.
Basically what needs to be adapted to make merb work with 0.10 is
merb_datamapper. If you're on merb edge, then also merb-actionorm
needs adaptions. Both is in my fork. It should be easy enough to
backport the changes to merb_datamapper in my fork to the 1.0.11
version of merb_datamapper, but I have no time/need to do it, since
I'm happy running off merb edge.
That said, I was talking to the maintainer of merb_datamapper and he
said that he wants to pull in my changes once 0.10 final is out.
However, that doesn't say anything about *when* the next merb gem with
support for datamapper 0.10 will be released. It's been far too quiet
on the merb front lately. Last commit on april 28 :-(
cheers
snusnu
It's for merb edge though, although backporting would be easy i guess
Andy Shipman
>
> Did you try my fork of merb?
> http://github.com/snusnu/merb
>
> From your original message I don't know if you just read my post, or
> if you actually tried it.
Merb edge.
> Basically what needs to be adapted to make merb work with 0.10 is
> merb_datamapper. If you're on merb edge, then also merb-actionorm
> needs adaptions. Both is in my fork. It should be easy enough to
> backport the changes to merb_datamapper in my fork to the 1.0.11
> version of merb_datamapper, but I have no time/need to do it, since
> I'm happy running off merb edge.
anything of note that was _specific_ to merb_datamapper other than
updating gem dependencies and fixing deprecation warnings. I
implemented those that I could see and still had no success.
Is there an obvious way to see what has changed _just_ to
merb_datamapper? I think the fact that it works for you may be tied
more closely to the edge changes than you suggest.
> That said, I was talking to the maintainer of merb_datamapper and he
> said that he wants to pull in my changes once 0.10 final is out.
> However, that doesn't say anything about *when* the next merb gem with
> support for datamapper 0.10 will be released.
Martin Gamsjaeger
On Fri, Jun 26, 2009 at 18:42, Andy Shipman<an...@cllearview.com> wrote:
>
>> Hey Andy,
>>
>> Did you try my fork of merb?
>
>> http://github.com/snusnu/merb
>>
>> From your original message I don't know if you just read my post, or
>> if you actually tried it.
>
> I haven't tried your fork, as yet, as I don't really want to be on
> Merb edge.
>
>> Basically what needs to be adapted to make merb work with 0.10 is
>> merb_datamapper. If you're on merb edge, then also merb-actionorm
>> needs adaptions. Both is in my fork. It should be easy enough to
>> backport the changes to merb_datamapper in my fork to the 1.0.11
>> version of merb_datamapper, but I have no time/need to do it, since
>> I'm happy running off merb edge.
>
> I took a look at some of the commits in your fork, but couldn't see
> anything of note that was _specific_ to merb_datamapper other than
> updating gem dependencies and fixing deprecation warnings. I
> implemented those that I could see and still had no success.
>
> Is there an obvious way to see what has changed _just_ to
> merb_datamapper? I think the fact that it works for you may be tied
> more closely to the edge changes than you suggest.
There is actually a little more than fixing deprecation warnings (not
that it's a lot!) but there's at least
http://github.com/snusnu/merb/commit/de57d2bc70723273b010169a96e685cee1dd2998
http://github.com/snusnu/merb/commit/9ee67bebe8b2fa608c1c1a06ae1edbd1b478f2fa
for merb_datamapper, the rest is mostly dependency upgrades,
merb-actionorm stuff and deprecation warnings
I don't think the above 2 commits are related to your problem though.
Are you sure you got everything you need for RC1 installed? Did you
install from gems.datamapper.org ?
It also might be a good idea to install everything directly from the
github repos and keep them uptodate
regularly. If you're willing to use RC1 (out of probably 4-5) maybe
you're fine with edge too?
>
>> That said, I was talking to the maintainer of merb_datamapper and he
>> said that he wants to pull in my changes once 0.10 final is out.
>> However, that doesn't say anything about *when* the next merb gem with
>> support for datamapper 0.10 will be released.
>
> Perhaps we need some input from the gem maintainer directly? ;-)
Andy Shipman
> Are you sure you got everything you need for RC1 installed? Did you
> install from gems.datamapper.org ?
I can run other DM code that isn't running in merb, so I'm sure I've
got all I need to run DM 0.10RC1
> It also might be a good idea to install everything directly from the
> github repos and keep them uptodate
> regularly. If you're willing to use RC1 (out of probably 4-5) maybe
> you're fine with edge too?
I git cloned your Merb, diff'd the merb_datamapper and made the non-
Action ORM changes to my local merb_datamapper and my test sqlite3 app
now works. I _think_ that's down to the changes to the automigration
using DataMapper.auto_migrate! directly.
With the test app working, I went back to my main development app and
discovered that I had :nullable => false in my migrations against
the :id keys, thus:
:id, Serial, :nullable => false
Now, I'm not sure if that is needed or not - obviously you don't want
null ids, so presumably they're not NULL by default? Anyway,
removing :nullable => false fixed the INSERT errors that I was seeing
when creating records. I've now moved on to another set of errors with
'cannot modify frozen object' and/or 'stack level too deep'.
I'll try and come back to this later to review further.
>>> cheers
>>> snusnu
Thanks for the help thus far.
Andy
Martin Gamsjaeger
On Mon, Jun 29, 2009 at 12:45, Andy Shipman<an...@cllearview.com> wrote:
>
> On 26 Jun 2009, at 20:26, Martin Gamsjaeger wrote:
>> Are you sure you got everything you need for RC1 installed? Did you
>> install from gems.datamapper.org ?
>
> I can run other DM code that isn't running in merb, so I'm sure I've
> got all I need to run DM 0.10RC1
>
>> It also might be a good idea to install everything directly from the
>> github repos and keep them uptodate
>> regularly. If you're willing to use RC1 (out of probably 4-5) maybe
>> you're fine with edge too?
>
> I git cloned your Merb, diff'd the merb_datamapper and made the non-
> Action ORM changes to my local merb_datamapper and my test sqlite3 app
> now works. I _think_ that's down to the changes to the automigration
> using DataMapper.auto_migrate! directly.
>
> With the test app working, I went back to my main development app and
> discovered that I had :nullable => false in my migrations against
> the :id keys, thus:
>
> :id, Serial, :nullable => false
>
> Now, I'm not sure if that is needed or not - obviously you don't want
> null ids, so presumably they're not NULL by default?
Anyway,
> removing :nullable => false fixed the INSERT errors that I was seeing
> when creating records. I've now moved on to another set of errors with
> 'cannot modify frozen object' and/or 'stack level too deep'.
These could obviously have quite a few reasons, but related to "cannot
modify frozen object" i remember a ticket where the poster was trying
to change already destroyed objects (possibly in the context of
many_to_many). For "stack level too deep", i remember at least one
ticket where the poster was calling #all_valid? on a self referential
many_to_many association, leading to infinite loops (it does a
recursive walk of all associations).
Also, be aware of the fact that dm tries to save "the whole object
tree" for you when you call #save on a resource. This means that dm
will try to save all parent (belongs_to) and child (has) associations
that are loaded at the time you do a #save.
Ashley Moran
On 29 Jun 2009, at 13:14, Martin Gamsjaeger wrote:
> It's definitely a good idea to have a look at the tickets!
I'm really eager to get Merb working with 0.10rc1, if not only for the
fact it now saves parents before self and children. Thanks to my
housemate buying 3 bottles of cheap wine, I'm on a drunken ticket
reporting spree. Anything to be logged here? =)
--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashleymoran
http://aviewfromafar.net/
http://twitter.com/ashleymoran
Andy Shipman
>> I git cloned your Merb, diff'd the merb_datamapper and made the non-
>> Action ORM changes to my local merb_datamapper and my test sqlite3
>> app
>> now works. I _think_ that's down to the changes to the automigration
>> using DataMapper.auto_migrate! directly.
>>
>> With the test app working, I went back to my main development app and
>> discovered that I had :nullable => false in my migrations against
>> the :id keys, thus:
>>
>> :id, Serial, :nullable => false
>>
>> Now, I'm not sure if that is needed or not - obviously you don't want
>> null ids, so presumably they're not NULL by default?
>
> Yes, they are not null by default, :id, Serial should be enough
I've reviewed this further and :id, Serial isn't actually enough with
0.10RC1 - that's because with Postgres (and maybe others) it doesn't
actually create a Serial column if you're using rake db:migrate, as
apposed to Datamapper.automigrate!
> It's definitely a good idea to have a look at the tickets!
It is! Here's one created regarding this very matter - http://datamapper.lighthouseapp.com/projects/20609/tickets/938-datamapper-010-does-not-make-serial-properties-serial-in-postgresql-using-dm-migrations
With that done, I was able to make more progress with a 'standard'
merb_datamapper. I'm not 100% there yet, however, so I'll let you know
what other changes I had to make, if any.
Andy
Ashley Moran
On 1 Jul 2009, at 20:02, Andy Shipman wrote:
> It is! Here's one created regarding this very matter -http://datamapper.lighthouseapp.com/projects/20609/tickets/938-datamapper-010-does-not-make-serial-properties-serial-in-postgresql-using-dm-migrations
Which Andy was incremental in isolating ;o)