Product-Developers Digest, Vol 4, Issue 5

[Martin Aspeli]

Charles Pace wrote:
> 
> 
>> > Prior Art Search (~$1.5k)
>> > ------------------------------------
>> >
>> > Create a python application that will walk a web site with
>> > bibliographic data, gathering author names. These names and their
>> > papers' names will be stored in a couple of DBMS tables. Application
>> > will keep track of how often it has crawled and extracted data from
>> > these web sites. When the web sites change (date/diff) they will be
>> > crawled again and new information will be added to the database tables
>> > (and timestamp noted in table entries).
>> >
>> > A second application will take the authors' names and search the
>> > USPTO.gov patent database for these authors and retrieve possible
>> > patent entries associated with those authors and store these entries
>> > in a table.
>> >
>> > A GUI will be used to list the authors and their respective
>> > papers/patents. A 5-star rating will be used to rate the "match"
>> > through user input. Additionally, a button will be used by the user to
>> > indicate a mismatch.
>> >
>> > The USPTO queries will be performed on a schedule, and redundant
>> > information will be suppressed from database insertion.
>> >
>> > All code is to be written in Python in the Plone framework, and
>> > database operations should all use SQLAlchemy.
>>
>> I'd say a week to write, test and develop this sounds ambitious, but I
>> may have over-estimated the scope.
> 
> The requirement assumed familiarity by the developer with these
> technologies and/or an interest in working with them.  In addition,
> while we will own the work product, we don't mind if he developer
> wishes to reuse the work product - even creating an open source
> version.
> 

Well, I am familiar with all of these tools ;-)

So it looks like you're asking for people with synergy of needs, then. :)



>>
>> > Small DBMS Example (~$1.0k)
>> > ------------------------------------
>> >
>> > Take create statements for five tables and create the ArchGenXML UML
>> > diagram. From this, use the Archetype tools to generate the Plone
>> > product for this UML. As a final step, create the SQLAlchemy code to
>> > back the product content to a postgress DB with the same tables you
>> > started with.
>> >
>> > In other words, we would like to have a Plone product for a set of
>> > tables that is generated from a UML diagram, and then backed by the
>> > same tables using SQLAlchemy.
>> >
>> > We would then be able to change the UML and re-generate the Plone
>> > product - resulting in another ZODB backed set of objects. And, after
>> > having the first SQLAlchemy mapping, we would then be able to more
>> > easily change the ZODB over to SQLAlchemy/Postgress.
>>
>> $1,000 and 1 week to do this sounds very, very ambitious. You'd need to
>> write something to render XMI files, parse Create Table statements and
>> then write an Archetypes storage engine for SQLAlchemy (which I believe
>> to be possible, but not trivial). This won't buy you changeability, by
>> the way - you may be able to store field values in an RDBMS, but you
>> will not be able to switch off the ZODB, and the content items would
>> still live in the ZODB, where their main metadata and location
>> information would live.
>>
>> I also don't see what the UML diagram buys you here.
> 
> The thinking was that the system would follow the Archetype example -
> where they start in a diagramming tool and generate much of the Plone
> product.  Then, for a SQLAlchemy example - they show how easily
> existing objects can be introspected to generate RDBMS schema.  This
> would be the union of those examples.  Once the
> UML->Plone_Product->RDBMS chain is established, then DB & UI changes
> would be alterations in this chain, mostly through the UML tool.
> 

I'm just trying to tell you it's not quite as easy as that, and I'm not
convinced that using an SQLAlchemy storage for the AT content actually gives
you the benefits you think it does (it'll allow you to inspect that
content's fields via the database, but not its location, security or other
metadata; it will not allow you to lose the ZODB entirely, nor will it allow
you to expose existing records in the database as content items without
first creating a piece of content in the ZODB).

In terms of relative complexity, I'd say this is a fair bit harder (if you
want something generic and robust) than the first (quite specific) chunk of
functionality. It therefore seems odd that you're suggesting it's worth 1/3
less.

Martin
-- 
View this message in context: http://www.nabble.com/Re%3A-Product-Developers-Digest%2C-Vol-4%2C-Issue-5-tf3877545s20094.html#a10987875
Sent from the Product Developers mailing list archive at Nabble.com.