From brian.takita at gmail.com  Tue Dec  9 01:04:36 2008
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 9 Dec 2008 01:04:36 -0500
Subject: [Desert-devel] Desert Help
In-Reply-To: <35c88e510812051946t40df344ew782f327789620605@mail.gmail.com>
References: <20081205183837.50279185818C@rubyforge.org>
	<1d7ddd110812051447s4b2eda34l8c7c9b65431bb18d@mail.gmail.com>
	<35c88e510812051946t40df344ew782f327789620605@mail.gmail.com>
Message-ID: <1d7ddd110812082204l3fca9cc1o57399f0cd3ebfc24@mail.gmail.com>

On Fri, Dec 5, 2008 at 10:46 PM, Jonathan Greenberg
<greenberg at entryway.net> wrote:
> Thank you so much for responding.
Np. Thanks for using Desert.
> I am somewhat of a newbie to Ruby On Rails and programming in general so
> forgive me for leaning on your experience.
> I am a junior programmer for a small web software company called Entryway
> and we are excited about using desert to help modularize our e-commerce
> engine for our clients.
> Yes, I ended up using Jeff Dean's patch locally in order to get desert
> running enough to test it on on our application. I did not find that my
> version of desert had incorporated his fix.
Thanks for the info. I'll take a look.
> I also ran into a couple of other little things. First I needed to add a few
> other load paths since we like to have lib and notifier folders in our app
> folder.
That makes sense.
> Also I had to change the plugin_schema_info version datatype to
> decimal so that the timestamp generated migration number would fit with
> postgres. Those were minor things that I thought I would just mention.
Thanks again for the info. I'll file a bug report.
> The main problem is that as we continue to develop our e-commerce plugin
> more migrations get added. However, there seems to be no easy way to run the
> new migrations from the parent application. If I change the migration number
> in the 'migrate_plugin' migration it tries to run the plugin migrations from
> the beginning and of course blows up.
So you use migrate_plugin within a migration in your application? What
do you mean by "change the migration number"?
> It would be great if the
> plugin_schema_info table held all the plugin migration numbers like the
> schema_migration table does. Perhaps it is supposed to something is
> configured wrong like it is trying to run against an  earlier Rails version
> (we are using 2.1 currently).
Thats certainly possible.
> FInally, I also am having the problem trying to run rake
> desert:testspec:plugins task. As others have noted as well
> (http://rubyforge.org/tracker/index.php?func=detail&aid=21564&group_id=6426&atid=24920 )
> rake does not seem to list this task.
Try updating and adding
  require "desert/tasks"
to one of your rake files.
> Also is there support for running
> individual specs and for using autotest?
To run individual specs, have you tried:
spec path/to/file.rb --line 66?

We have not tried Desert with autotest. I would not expect it to work.
Have you tried it?
> On last thing, we were wondering whether desert is or will be compatible
> with Rails 2.2.2. If so when?
I'll have time to work on it on Wednesday. That will probably be the earliest.
> Thanks again so much for your time and attention.
> Jonathan.
You're welcome. I HTH,
Brian
>
> On Fri, Dec 5, 2008 at 5:47 PM, Brian Takita <brian.takita at gmail.com> wrote:
>>
>> On Fri, Dec 5, 2008 at 1:38 PM, Jonathan Greeenberg
>> <greenberg at entryway.net> wrote:
>> > I have been appreciating the Desert plugin but I am having trouble with
>> > migrations and Specs. I have seen other people reporting similar problems in
>> > Rubyforge.
>> If you are referring to,
>>
>> http://rubyforge.org/tracker/index.php?func=detail&aid=20782&group_id=6426&atid=24920,
>> I think it was fixed. I'll need to follow up on that though.
>> >
>> > Are you able to offer any technical support at this time?
>> Sure, what issues are you having?
>> >
>> > Thanks.
>> >
>
>