| 00:37.06 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm jkakar (n=jkakar@S0106001ee57a879c.vc.shawcable.net) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm mzz (n=mzz@flits102-164.flits.rug.nl) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm gabriel (n=gabriel@24.141.18.191) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm maxb (n=maxb@jabberwock.vm.bytemark.co.uk) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm bac (n=bac@canonical/launchpad/bac) [NETSPLIT VICTIM] |
| 00:37.06 | *** join/#storm therve (n=therve@xvm-14-10.ghst.net) [NETSPLIT VICTIM] |
| 03:15.31 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 05:34.47 | *** join/#storm stub (n=stub@ppp-58-8-6-91.revip2.asianet.co.th) |
| 05:45.55 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 07:57.53 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 10:00.44 | *** join/#storm gabriel (n=gabriel@node-1191.tor.pppoe.execulink.com) |
| 10:09.32 | *** join/#storm zmijunkie (n=chatzill@i53873C5E.versanet.de) |
| 11:27.58 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 13:05.52 | *** join/#storm drudi (n=drudi@189.64.41.49) |
| 14:03.55 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 14:22.06 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 14:45.45 | *** join/#storm keppla (n=keppla@i577B0B06.versanet.de) |
| 14:45.56 | *** join/#storm artista_frustrad (n=artista_@201-25-168-225.ctame704.dsl.brasiltelecom.net.br) |
| 15:26.34 | *** join/#storm artista_frustrad (n=artista_@201-14-26-126.ctame704.dsl.brasiltelecom.net.br) |
| 16:38.34 | *** join/#storm gabriel (n=gabriel@24.141.36.30) |
| 16:57.34 | *** join/#storm WebMaven (n=webmaven@68.35.24.218) |
| 17:01.59 | *** join/#storm fcorrea (n=fcorrea@189-54-35-134-nd.cpe.vivax.com.br) |
| 17:38.02 | *** join/#storm jukart (n=jukart@d86-32-163-51.cust.tele2.at) |
| 17:43.02 | *** join/#storm artista_frustrad (n=artista_@201-14-26-126.ctame704.dsl.brasiltelecom.net.br) |
| 18:09.01 | *** join/#storm gabriel (n=gabriel@mc-126-86.IPReg.McMaster.CA) |
| 18:11.32 | *** join/#storm artista_frustrad (n=artista_@201-14-26-126.ctame704.dsl.brasiltelecom.net.br) |
| 18:43.22 | *** join/#storm sidnei (n=sidnei@plone/dreamcatcher) |
| 19:26.53 | *** join/#storm artista_frustrad (n=artista_@200-193-151-65.ctame704.dsl.brasiltelecom.net.br) |
| 20:31.24 | *** join/#storm shaunm (n=shaunm@c-98-212-133-244.hsd1.il.comcast.net) |
| 20:48.28 | *** join/#storm srichter (n=quassel@c-76-19-135-180.hsd1.ma.comcast.net) |
| 20:48.36 | srichter | hi everyone |
| 20:48.46 | srichter | I have some basic questions |
| 20:49.18 | srichter | 1. Given a class based on the Storm object, can the API create the table for me? |
| 20:49.38 | srichter | (or do I have to create it by hand?) |
| 20:50.02 | srichter | 2. What is the best and most reliable way to reset a DB using storm? |
| 20:51.56 | srichter | jkakar: sidnei: nag, nag :-) ^^^ |
| 20:58.29 | jkakar | srichter: Hi. :) |
| 20:58.41 | jkakar | srichter: 1. No, you have to create it yourself. |
| 20:58.42 | srichter | jkakar: hi :-) |
| 20:58.47 | jkakar | srichter: 2. Do you mean for unit tests? |
| 20:58.56 | srichter | yeah, or even for manual testing |
| 20:59.31 | srichter | of course, I can just drop the table and recreate it manually, but I thought there might be something automatic |
| 20:59.36 | jkakar | srichter: What we do, with PostgreSQL, in our test suite is to: check if tables exist, if they do then run DELETE FROM in each one, and it they don't create empty databases from the ground up. |
| 20:59.50 | jkakar | srichter: Nope, nothing automatic. |
| 21:00.01 | srichter | ok, right, I'll do that then |
| 21:00.17 | jkakar | srichter: We have a bunch of code in Landscape that deal with patches and all this creation, dropping, deletion stuff. |
| 21:00.26 | srichter | I think if I keep using storm, automating the table creation would be a first feature for me to implement |
| 21:00.28 | jkakar | srichter: It could probably be open sourced, but no one has gotten around to it. :/ |
| 21:00.47 | srichter | ok |
| 21:00.49 | jkakar | srichter: A lot of people want that. Would be a nice little extension library helper thing. |
| 21:00.57 | srichter | well, as you might know I am also a Z3 developer |
| 21:01.22 | srichter | preferably I just want to decorate my zope.itnerface interfaces a little bit more and get the storm object for free |
| 21:01.23 | jkakar | srichter: fwiw, the code I'm talking about uses manually created SQL to create tables so I doubt it would totally satisfy your needs. |
| 21:01.37 | jkakar | srichter: Yep! I might have even met you? Were you at PyCon 2007? |
| 21:01.57 | jkakar | srichter: Yeah, that'd be nice. |
| 21:02.01 | srichter | oh yes, I dropped in briefly, I think |
| 21:02.26 | jkakar | Thought so. :) |
| 21:02.43 | srichter | I am also planning to go to PyCon 2010 |
| 21:03.11 | jkakar | I'm thinking about attending too. |
| 21:03.22 | srichter | jkakar: where do you live? |
| 21:03.26 | jkakar | srichter: There's been some discussion about schema generation on the mailing list. |
| 21:03.31 | jkakar | srichter: In Vancouver, Canada. |
| 21:04.06 | jkakar | srichter: One of the ideas that bubbled to the top of the discussion was to have a schema argument on columns. It would be a place you put extra information related to the schema. |
| 21:04.24 | jkakar | srichter: So for example, if your column needs a UNIQUE constraint you can't currently figure that out from Storm alone. |
| 21:05.19 | jkakar | srichter: If you could do something like title = Unicode(allow_none=False, schema={"unique": True}) then a schema tool that processed Storm classes could use the extra data to create the column properly. |
| 21:05.44 | jkakar | srichter: Also, I'd guess you'd want a way to decorate a class as needing an index. |
| 21:25.54 | srichter | jkakar: sorry, I had to answer the door and it took a moment |
| 21:25.58 | srichter | I am back now |
| 21:26.48 | srichter | well, I was thinking about something along the lines of: |
| 21:26.50 | jkakar | srichter: np. |
| 21:27.04 | srichter | class IPerson(zope.interface.Interface): |
| 21:27.21 | srichter | <PROTECTED> |
| 21:27.36 | srichter | <PROTECTED> |
| 21:27.42 | srichter | and then: |
| 21:27.49 | srichter | class Person(Storm): |
| 21:28.07 | srichter | <PROTECTED> |
| 21:28.23 | srichter | <PROTECTED> |
| 21:28.30 | srichter | or something like that |
| 21:28.56 | srichter | in the simple case you would not need a storm decorator in front of the schema field at all |
| 21:29.45 | srichter | this would be actually easy to implement, since the zope.interface implementation already has an API for additional meta data, so recording the storm property would be fairly straight forward |
| 21:30.18 | srichter | then I would of course just like to say: storm.createTableFor(Person) |
| 21:31.10 | srichter | I can see that you do not want this to be part of the basic storm API, since not all objects are represented by one complete table, but when you develop a new project that's certainly very helpful |
| 21:31.30 | srichter | note that I could also do: storm.resetTableFor(Person), etc |
| 21:32.32 | srichter | jkakar: my main problem right now is that I have defined my schema in 3 places: interface, class and in the create table call |
| 21:32.45 | srichter | coming from ZODB that's really annoying ;-) |
| 21:34.10 | jkakar | srichter: Yeah, I totally understand. :) |
| 21:34.24 | jkakar | srichter: What you propose sounds great for a Zope-focused solution. |
| 21:34.51 | srichter | yeah, I definitely do not think it is a general solution |
| 21:35.11 | srichter | however, zope.interface is used by other projects as well and they would benefit in the same way |
| 21:36.20 | srichter | I also need to figure out how to do annotations well with an RDB |
| 21:39.05 | srichter | jkakar: but independent of my comments, how do you manage the schema definitions and the repetition in the storm class and table creation code? |
| 21:39.09 | srichter | just live with it? |
| 21:39.46 | jkakar | srichter: We have a CREATE TABLE statement for each Storm class. |
| 21:39.46 | jkakar | srichter: They are always in sync. |
| 21:40.05 | jkakar | srichter: When we need to make a change, like add a new column for instance, we update the Storm class and this ground-up schema. |
| 21:40.16 | srichter | how do you ensure they are in sync? |
| 21:40.19 | jkakar | srichter: We also create a patch (with a unique ID) that makes the same change to existing deployments. |
| 21:40.30 | jkakar | srichter: With our test suite, basically. |
| 21:40.39 | srichter | ok, fair enough |
| 21:40.58 | jkakar | srichter: What we don't do a great job of right now is making sure that original schema + all patches to date == ground-up schema. |
| 21:41.17 | srichter | yeah, but that's a hard issue anywhere |
| 21:41.19 | jkakar | srichter: It's not that hard to do, but it isn't automated. |
| 21:41.27 | srichter | this is hard in the ZODB as well |
| 21:41.37 | srichter | well, that's what I mean :-) |
| 21:41.50 | jkakar | Yeah. :) |
| 21:42.17 | srichter | usually I write tests that check that the patch is complete, which is not too hard since the app usually breaks if the schema is not correct |
| 21:42.33 | jkakar | Right. |
| 21:43.25 | srichter | jkakar: oh one final question: there were some posts about a zope IContainer implementation in 2007; was there ever a checkin of that code? |
| 21:43.38 | jkakar | srichter: There wasn't, no. |
| 21:43.56 | srichter | (I am just trying to collect some ideas for an add-on package providing some of this high-level functionality) |
| 21:45.16 | jkakar | Cool. |
| 21:46.02 | srichter | jkakar: where are you storing the table definition in relation to the object? as an attribute? in the same module? |
| 21:47.02 | jkakar | srichter: In a completely separate module. |
| 21:47.59 | jkakar | srichter: We have a landsape.schema.$(db) package with an __init__ that contains functions to manipulate a data store. |
| 21:48.18 | jkakar | srichter: The package itself contains the patch_##.py files created so far. |
| 21:48.45 | srichter | ok |
| 21:48.51 | jkakar | IOW, model objects don't have any idea of what their database schema is, or even what database they're talking to. |
| 21:49.47 | srichter | right, because the store is handling that mapping |
| 21:50.03 | jkakar | Yeah. |
| 21:50.10 | srichter | ok, that's a nice abstraction |
| 21:50.17 | jkakar | It's not a necessary coupling, though it seems to be one lots of people want. |
| 21:50.17 | srichter | I'll keep that in mind |
| 21:50.21 | jkakar | Cool! |
| 21:50.49 | srichter | has not done RDB and ORMs in 5-6 years |
| 21:51.33 | srichter | jkakar: OT: what Web platform does landscape use and is it competing with Red Carpet? |
| 21:54.34 | jkakar | srichter: We're based on Zope 3. I don't know what Red Carpet is. |
| 21:55.37 | srichter | jkakar: it was a package management and distribution application by Ximian |
| 21:56.28 | srichter | jkakar: Zope 3, cool. :-) So are you duplicating the schema definition in the itnerfaces and implementation? (I would assume so, since there is a certain impedence mismatch) |
| 22:08.03 | jkakar | srichter: Sorry, phone. |
| 22:08.53 | jkakar | srichter: We do have duplication with interfaces, yes. Though we don't use them as heavily as most Zope 3 apps seem to. |
| 22:23.33 | *** join/#storm gabriel (n=gabriel@mc-126-90.IPReg.McMaster.CA) |
| 22:59.52 | *** join/#storm ivan` (n=ivan@ludios.net) |