Hi, We already have API documentation generated from the source:
http://people.canonical.com/~jkakar/storm/ We can reference the API from the manual, but I don't think we need to reproduce it there. Thanks, J. On Wed, Nov 10, 2010 at 4:23 PM, Nachiketa Mishra <[email protected]> wrote: > This is a good start. What about API documentation ? Should that be a > section of it's own or should it fall into ORM section. > > On Wed, Nov 10, 2010 at 9:16 AM, Jamu Kakar <[email protected]> wrote: >> >> Hi, >> >> Well, I think we should brainstorm about the structure a bit, but as a >> starting point, what do you think about having these broad sections: >> >> * Object relational mapper - this section describes how to use the >> ORM features of Storm. The focus should be on describing how >> to create Storm classes, how to establish a connection to the >> database, how to implement hooks for invalidation and such, >> etc. Basically, this broad section is focused on how to use >> Storm. >> >> This section should be readable from beginning to end, at the >> end of which the reader should have a very good understanding >> of how to use the various features of Storm. It should also be >> broken into sections, such that it can be used as a reference, >> once the user knows what they want to look for. Finally, it >> should be example-heavy, to make learning as easy as possible. >> >> * Framework integration - this section describes the integration >> tools for using Storm with Zope 3 and with Django. These >> should assume knowledge of how to use Storm and focus on >> describing how the framework hooks work and include examples to >> help users quickly get Storm integrated with these frameworks. >> >> * Schema management - this section describes the schema management >> tools in Storm with examples about how to use them. >> >> * Extending Storm - this section describes the expression and >> property systems. The audience for this section is a user that >> wants to extend Storm by providing their own expressions or >> implementing custom properties. It should describe the >> compilation process, the way precedence is handled, that way >> values are pushed to and pulled from the database, etc. >> >> Each of these broad sections would have subparts, but for now I think >> brainstorming about the broad organization is a good first step. >> >> Thanks, >> J. >> >> On Wed, Nov 10, 2010 at 3:57 PM, Nachiketa Mishra <[email protected]> wrote: >> > That definitely works. I will go ahead and pull the branch. How do you >> > want >> > to structure the documentation ? >> > >> > On Wed, Nov 10, 2010 at 8:32 AM, Jamu Kakar <[email protected]> wrote: >> >> >> >> Hi Nachiketa, >> >> >> >> (Please use 'Reply all' to make sure the list is included when you >> >> respond to messages) >> >> >> >> Great, glad to hear it! We'd would *love* help with documentation, >> >> it's a real sore spot for the project. I've started a branch: >> >> >> >> lp:~jkakar/storm/documentation >> >> >> >> With some very basic beginning work at putting a manual in place. >> >> Maybe we can work together to develop and outline for it and then >> >> start to fill in sections? >> >> >> >> Thanks, >> >> J. >> >> >> >> On Wed, Nov 10, 2010 at 3:22 PM, Nachiketa Mishra <[email protected]> >> >> wrote: >> >> > This is great. >> >> > Thanks a lot. This worked perfectly. As I love storm, can I help in >> >> > documentation ? >> >> > Nachiketa >> >> > >> >> > On Wed, Nov 10, 2010 at 8:02 AM, Jamu Kakar <[email protected]> wrote: >> >> >> >> >> >> Hi Nachiketa, >> >> >> >> >> >> On Wed, Nov 10, 2010 at 2:57 PM, Nachiketa Mishra <[email protected]> >> >> >> wrote: >> >> >> > I have a type table with name, category_name and description and >> >> >> > some >> >> >> > audit >> >> >> > columns. With Storm I am trying to just get these three columns. I >> >> >> > am >> >> >> > new to >> >> >> > Storm and I am not able to figure out from the get_select_expr api >> >> >> > documentation, how to just fetch these three columns. >> >> >> >> >> >> Unless you want to perform a subselect, you don't need to use >> >> >> get_select_expr. Given a class: >> >> >> >> >> >> class Thing(Storm): >> >> >> >> >> >> __storm_table__ = "thing" >> >> >> >> >> >> id = Int(primary=True) >> >> >> name = Unicode() >> >> >> category_name = Unicode() >> >> >> description = Unicode() >> >> >> audit_stuff = Unicode() >> >> >> >> >> >> You can get just the columns you want with: >> >> >> >> >> >> result = store.find(Thing) >> >> >> result = result.values(Thing.name, Thing.category_name, >> >> >> Thing.description) >> >> >> for name, category_name, description in result: >> >> >> print name, category_name, description >> >> >> >> >> >> The ResultSet.values method is handy when you have a result set that >> >> >> would normally yield objects, but for which you only want columns. >> >> >> If >> >> >> you know you'll only ever want columns from the result set you can >> >> >> specify them in the call to find: >> >> >> >> >> >> result = store.find((Thing.name, Thing.category_name, >> >> >> Thing.description)) >> >> >> for name, category_name, description in result: >> >> >> print name, category_name, description >> >> >> >> >> >> I hope this helps! >> >> >> >> >> >> Thanks, >> >> >> J. >> >> > >> >> > >> > >> > > > -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
