[Umlaut-general] 1st resolution

Ross Singer rossfsinger at gmail.com
Mon May 19 10:56:26 EDT 2008


What is MySQL specific?  It seems worthwhile (in my mind, at least) to
remove any dependencies to a particular stack since that could
potentially be prohibitive to broader adoption.

I know the migrations have (or at least had, I can't remember if I
checked in the changes) some MySQL-isms in them, but I successfully
got the Umlaut running with Postgres last year with pretty minor
changes to the migrations.

Another useful endeavor in my mind would be getting Umlaut to run in JRuby.

My fear is that a lack of stack independence points to some bigger
flaws under the hood that will expose themselves later.

Maybe it would be worthwhile for us to come up with a priority list
and justification as to what we hope the outcomes of the priorities
are?

-Ross.

On Mon, May 19, 2008 at 10:31 AM, Jonathan Rochkind <rochkind at jhu.edu> wrote:
> I have my SFX itself configured to do both CrossRef and Pubmed lookups.  So
> I don't use the Umlaut CrossRef and Pubmed services---instead my Umlaut
> makes the request to SFX, SFX enhances metadata with crossref and pubmed,
> and returns this metadata to umlaut.  The current Umlaut SFX adaptor does
> take advantage of any added metadata from SFX to enhance the Umlaut metadata
> structures.
>
> Jason, I would not recommend trying to use Postgres as an initial project.
> I think there are currently some MySQL specific things in there. That could
> certainly be changed, and that would be an improvement to Umlaut, but I
> think there are bigger bang-for-the-buck projects that I'd recommend as a
> starting point.
>
> [For those who don't know, Jason is 'interning' with me this summer working
> on Umlaut].
>
> Jonathan
>
> Jason Ronallo wrote:
>>
>> Hi, Ross,
>> Response inline.
>>
>> On Mon, May 12, 2008 at 4:31 PM, Ross Singer <rossfsinger at gmail.com>
>> wrote:
>>
>>>
>>> Wow, I think is, like, our first ever email...  And it's (mostly) a
>>> success story!
>>>
>>
>> Yeah, I was quite happy to have gotten it to basically run.
>>
>>
>>>
>>> You can probably also turn on Crossref -- the API key is optional and
>>> there's the possibility that they can throttle you, but I think it's
>>> probably pretty unlikely.
>>>
>>
>> I uncommented the Crossref service in services.yml and uncommented
>> Crossref in institutions.yml as well. But it times out. It looks not
>> to be working right now.
>>
>>
>>
>>>>
>>>>  Because I wasn't using a direct connection to the SFX database, things
>>>>  like title search (with auto suggestions?) and A-Z list failed. For a
>>>>  journal title search I get the error that the table
>>>>  umlaut_dev.AZ_TITLE doesn't exist. Do you create that with your
>>>>  load_sfx_urls rake task which draws in data directly from the SFX
>>>>  database? If I set config.app_config.use_umlaut_journal_index to true,
>>>>  then it fails because acts_as_ferret isn't loaded. I suppose the
>>>>  needed info hasn't been pre-fetched from the SFX server database. Was
>>>>  acts_as_ferret used by Ross to do things like categories?
>>>>
>>>
>>> What SFX server are you using?  I didn't directly go off the DB either
>>> (since SFX was hosted consortially for Tech, this wasn't an option).
>>> Instead, I had a python script to import the tab delimited export
>>> files into mysql (doing this in python took about 1/5 the time of the
>>> equivalent ruby script) and then I'd reindex the ferret index after it
>>> completed.  At Tech, we didn't use the categories, since the
>>> librarians didn't like them.
>>>
>>
>> For now I'll probably just skip A-Z functionality and forge ahead.
>>
>>
>>
>>
>>>>
>>>>  Would it be helpful to include a step by step on creating a mysql
>>>>  development database?
>>>>
>>>
>>> Do the migration scripts not work right?
>>>
>>
>> The migrations seem to work just fine. I was talking more about the
>> more mundane details of creating the mysql database. For instance I
>> issued the following so that it wasn't using the root user. I thought
>> it might be good to include something fuller like this in the docs,
>> but before I did I wanted another set of eyes on it.
>>
>> CREATE DATABASE umlaut_dev DEFAULT CHARACTER SET 'utf8';
>> CREATE USER umlaut;
>> SET PASSWORD FOR 'umlaut'@'localhost' = PASSWORD('umlaut');
>> GRANT ALL ON umlaut_dev.* TO 'umlaut'@'localhost';
>>
>>
>>>>
>>>>  Now that I've got it up once, I'm going to try installation and
>>>>  configuration again on a fresh install of Ubuntu.
>>>>
>>>
>>> While you're at it, it might be interesting to try it with postgres or
>>> firebird or something.  I mean, if you're up to it.
>>>
>>
>> Sounds like a good plan. I'll give postgres a try.
>>
>> Jason
>> _______________________________________________
>> Umlaut-general mailing list
>> Umlaut-general at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/umlaut-general
>>
>
> --
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886 rochkind (at) jhu.edu
>
> _______________________________________________
> Umlaut-general mailing list
> Umlaut-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/umlaut-general
>


More information about the Umlaut-general mailing list