More 'About Storm'

[Tim Stebbing]

I'm guessing from your mention of 20+ years experience  with things
like delphi, MS Access etc that you may be misunderstanding the layer
that storm operates at. Storm is a thin layer over writing SQL
yourself, your questions could be directed to the postgres mailing
list and make similar sense, "I know this 'sql' is great, but how do I
hook it up to wxWidgets?"

The way you 'hook it up' to your gui is by writing a program, storm
provides a data layer you can use in your application, personally if I
wanted to write a GTK app that used storm I'd grab a framework like
twisted, but thats really up to you, your project requirements etc.

good luck

-tjs

On 7/12/07, AlphaCentauriSoftware <acsoft at streamyx.com> wrote:
> Hi everyone:
>
> I just joined the storm mailing list and saw the email below from Stuart Bishop.
>
> When I first saw storm being mentioned and checked out the tutorial I got really excited.
>
> however, it didn't last very long. (yes, yes, i know storm is just an infant and things need to be put in place)
>
> I have been programming database applications for almost 20+ years and wanting to get away from delphi, visual foxpro and microsoft access; so i started looking for more info on storm--even googled it to disappointment. and that's why i joined this list.
>
> The first question that came to my mind is how is storm going to help me? Although the tutorial on the storm page showed me examples (which got me excited seeing its simplicity), I couldn't find answers about how can i code these features into an app. I only understood it to be a data store, but how do I implement it? how do i wire it up with an interface for end-users?
>
> to add to stuart's questions:
>
> My questions would be like:
>
> -- what widget system would i use to work with this store? wxWidgets, Qt? examples please...
> -- how would i populate these widgets with data from the data store?
> -- how would i make the widgets data aware?
> -- how would i commit the data updates in the widgets?
> -- how is the store used to refresh pagination in a datagrid?
> -- can the store cache be used offline and then subsequently be used to update the backend db?
> -- is the data store synchronized with the db? if not how do we check before committing updates?
> -- how are database error messages handled by the store so we can inform users in the client application? or decide upon a course of action.
> -- how do we work with stored procedures at the back-end db?
> -- etc...
> -- python is cross-platform, but what is the store's compatibility with win32, gtk, kde? what are the nuances? (surely, i'm gonna get shot here by someone on the list as a stupid question)
>
> whatever stuart says below is great, it throws a lot more light on storm.
>
> my questions however start from the view of a person actually coding a database app and how to wire it all up?
>
> i'm still excited about storm and hope this is what database app programmers are looking for. thanks for the great job done.
>
> best regards
> ram sambamurthy
> kuala lumpur, malaysia
>
> PS: i'm subscribed to the digest so it becomes a little difficult to reply. pardon me if i'm not following any protocol such as replies come at the end and not at the beginning. does this list practice anything like that?
>
> -------------------------------------------
> Date: Thu, 12 Jul 2007 07:31:35 +0700
> From: Stuart Bishop <stuart.bishop at canonical.com>
> Subject: More 'About Storm'
> To: storm at lists.canonical.com
> Message-ID: <46957667.1070300 at canonical.com>
> Content-Type: text/plain; charset="utf-8"
>
> I think there is more information needed in the About Storm section on the
> storm.canonical.com front page. Something like:
>
> Storm is different to other Python ORMs:
>
>  * Designed from day one to be database administrator friendly.
>  * Designed from day one to work both at the low end, with trivial small
> databases, and the high end, with applications accessing billion row tables
> and committing to multiple database backends.
>  * Designed from day one to work both with thin relational databases, such
> as SQLite, and big iron systems like PostgreSQL, DB2 & Oracle.
>  * Distributed database integrity using two-phase commit (if your Python
> driver and database backend support it).
>  * Storm does not dictate your datamodel.
>  * Storm lets you efficiently access and update large datasets by allowing
> you to formulate complex queries spanning multiple tables using Python.
>  * Storm lets you fallback to SQL if needed (or if you just prefer),
> allowing you to mix 'old school' code and ORM code
>
> These are all from my perspective, so may not be general enough for the
> front page. Other people might have points or catch phrases to add too, but
> we don't want the section to grow too big so high level points should
> replace low level points.
>
>
> --
> storm mailing list
> storm at lists.canonical.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
>


-- 
Timothy J Stebbing