Hi Marek,
yes, Namshin set up a pygr.Data mysql resource database for all our
leelab internal resources. The database name is PYGRDB_JAN06, and the
table name is pygrdata, so you would add mysql:PYGRDB_JAN06.pygrdata
to your PYGRDATAPATH, assuming that you have configured your ~/.my.cnf
config file with the mysql server, username, and password info. I'll
give you that separately.
More responses below.
-- Chris
On Jan 23, 2009, at 8:50 AM, Marek Szuba wrote:
> Hello Chris,
>
> Attached you will find a patch which attempts to address Pygr issue
> 14.
> It does the following:
> - allows specifying the type of matching to be performed. Types
> supported at present are 'p', which engages old
> exact-match-on-beginning behaviour (default), and 'r', which enables
> regex support via Python's standard re module;
> - gives pattern a default value of '' so that pygr.Data.dir() can be
> called instead of pygr.Data.dir('') to get all IDs;
> - adds missing description string to ResourceDBMySQL.dir().
I'll take a look. I'll be back in LA on the 28th.
>
>
> The main part of this patch is of course adding support for regular
> expressions. I have confirmed that regex search patterns work when
> querying ResourceDBShelve, they also appear to work in client-server
> mode (I launched my own server and could see the method being called
> correctly in its logs, however it seems I didn't configure data
> sources
> correctly because dir() returns an empty list regardless of its
> arguments). As for SQL support, it SHOULD in principle work but I
> haven't tested it yet - is there a pygr.Data MySQL database around
> that
> I could use for this purpose?
Namshin can answer any questions you may have about creating and
starting an XMLRPC pygr.Data server. He can probably just point you
at the scripts that he uses.
>
>
> Please let me know what you think. Myself, I am not entirely happy
> with
> two things and will appreciate any suggestions on how to improve them:
> - the way matching type is selected - I can't quite put my finger on
> it but doing it the way it's done now feels clumsy, normally I would
> use an enumeration type for this but Python doesn't seem to provide
> them yet;
>
> - the fact re.compile is called in each backend's dir() rather than
> just once in the frontend, as it's inefficient if multiple backends
> are queried. The problem with the latter is that xmlrpclib doesn't
> know how to marshal compiled patterns.
I don't see this as a problem. XMLRPC only marshals a few primitive
data types, in keeping with its usage as a broad standard. You could
even argue that in our specific case this helps preserve modularity.
That is, the client shouldn't know the details of *how* the server is
going to implement the search. For example, someone could implement a
pygr.Data XMLRPC server in Java and have a completely different
internal data structure for compiled regexps. Or for that matter, the
python standard lib might someday make a change in that internal data
structure for compiled regexps, such that it would be incompatible
with a pattern compiled using an earlier version of Python...
>
>
> Cheers,
> --
> MS
> <pygrData-searchImprovements.patch>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
