| 00:53.58 | *** join/#storm nephish_ (n=nephish@69.55.30.106) |
| 00:54.35 | nephish_ | ok, easy one here, how do i remove an object from the database with a store ? |
| 00:55.06 | *** join/#storm jukart (n=jukart@bas12-toronto12-1096759409.dsl.bell.ca) |
| 00:57.34 | radix | nephish_: store.remove(object) |
| 00:57.38 | radix | nephish_: by the way! |
| 00:58.02 | radix | nephish_: You could have found that answer on http://twistedmatrix.com/users/radix/storm-api/storm.store.Store.html ;-) |
| 00:58.22 | radix | nephish_: I've recently made API documentation available, I just added the link to the web site today |
| 00:58.26 | radix | I suggest keeping that under your pillow :) |
| 01:00.57 | nephish_ | great link, thanks ! |
| 01:02.45 | nephish_ | oh, i had some trouble with the egg for python 2.4, dont quite remember the error, i am on my home computer now. |
| 01:03.13 | radix | nephish_: hrm. if you could find out what it is tomorrow that'd be great :) |
| 01:04.14 | nephish_ | will do. |
| 01:04.35 | ajmitch | radix: thanks for the docs :) |
| 01:04.52 | nephish_ | btw, i really appreciate all you guys patience and help the past week or so, i really dig this orm, much better than what i had in place before. |
| 01:05.04 | nephish_ | here and on the list, i mean |
| 01:07.37 | tjs | woooohoooooo |
| 01:07.41 | tjs | it is alive |
| 01:08.00 | tjs | just got my storm objects working in the zodb heirarchy |
| 01:11.00 | radix | nephish_: no problem |
| 02:06.15 | jkakar | tjs: Hey, that's awesome! Was they a reference that was causing Storm objects to be ZODBified? |
| 02:06.40 | jkakar | s/they/there |
| 02:06.42 | ajmitch | tjs: document it, please! :) |
| 02:07.02 | jkakar | tjs: Will you be able to open your reference management system? |
| 02:07.32 | jkakar | (ie: I assume you're not doing this stuff for an open source project) |
| 03:11.29 | tjs | jkakar: no a closed source project |
| 03:11.35 | tjs | but I can open source this stuff |
| 03:11.41 | jkakar | tjs: Nice |
| 03:11.53 | tjs | jkakar: you know what would -really- help me out? |
| 03:12.03 | jkakar | tjs: Oh? |
| 03:12.12 | tjs | being able to lookup the zstorm connection name from an object |
| 03:12.45 | tjs | that way I can more easily support multiple storm dbs |
| 03:13.00 | jkakar | tjs: You want something like: obj = SomeStormObject(); name_of_store = Store.store_name_of(obj); ? |
| 03:13.22 | tjs | that would do |
| 03:13.26 | tjs | anything like that |
| 03:13.36 | jkakar | tjs: I guess that's just Store.of(obj).name, really. |
| 03:14.04 | jkakar | Or at least, that would be the sensible API were it available. |
| 03:14.08 | tjs | currently a reference to a storm object looks like: ("storm", ("ClassName", "PriKeyAttr", 123)) |
| 03:14.33 | tjs | Id rather replace the "storm" part with the connection name |
| 03:14.49 | jkakar | I see, you want ("storm:storage-db-123", ("ClassName", ...)) |
| 03:14.57 | tjs | yeh |
| 03:15.09 | jkakar | That makes sense. |
| 03:15.29 | tjs | the first value is just a descriminator |
| 03:16.00 | tjs | the IReferenceBroker gets IHaveReferences implementations registered with it at runtime, with the descriminator |
| 03:16.13 | tjs | which it uses to know who to ask for what object |
| 03:17.45 | tjs | jkakar: would that be hard to add? |
| 03:18.43 | jkakar | tjs: I doubt it. |
| 03:22.25 | weatherman | storm/store-name r170 committed by jkakar@kakar.ca |
| 03:22.25 | weatherman | - Add optional name kwarg to Store constructor. |
| 03:22.26 | weatherman | - ZStorm passes the store name to the Store when it's constructed so |
| 03:22.30 | weatherman | <PROTECTED> |
| 03:22.36 | jkakar | tjs: ^ :) |
| 03:23.32 | tjs | jkakar: wooot |
| 03:24.19 | tjs | jkakar: I guess I should create a launchpad project for my reference thingo |
| 03:24.45 | jkakar | tjs: Yeah! |
| 03:25.22 | tjs | atm uts called 'crossrefs' |
| 03:25.24 | tjs | its |
| 03:25.57 | tjs | and its not really specific to storm, you could use it for any two data stores |
| 03:26.02 | jkakar | Cool. |
| 03:31.03 | jkakar | tjs: I've attached a branch to this bug: https://bugs.launchpad.net/storm/+bug/131221 |
| 03:31.04 | ubot3 | Malone bug 131221 in storm "Store should expose its name" [Undecided,New] |
| 03:31.27 | tjs | so the store knows its name |
| 03:31.40 | tjs | how do I get that from a given object? |
| 03:31.57 | tjs | if I have multiple stores |
| 03:32.02 | jkakar | tjs: Store.of(obj).name |
| 03:32.08 | tjs | ah |
| 03:36.51 | jkakar | I think I'm just about done for the day. |
| 03:37.17 | tjs | thanks :) |
| 03:37.29 | jkakar | tjs: np, hope it helps. |
| 03:38.43 | tjs | checking it out now :) |
| 03:51.59 | radix | wait, why would you add a name to Store instead of just being able to look up the name from the store in the utility? |
| 03:52.09 | radix | zstorm.get_name(store) -> name |
| 03:52.36 | tjs | either way, I don't really care |
| 03:52.46 | radix | e.g. zstorm.get_name(Store.of(random_object)) |
| 03:52.54 | radix | I think that'd be better, I guess I'll talk to jkakar about it tomorrow morning |
| 03:52.56 | radix | now it's bed time |
| 03:53.07 | tjs | radix: I think that jkakar's way allows this to be useful to people outside of zope |
| 03:54.30 | radix | what's the use? |
| 03:54.37 | radix | I think that change is touching stuff that it doesn't need to touch |
| 03:55.32 | radix | only ZStorm currently has any knowledge of "store names", and it's totally possible to leave that knowledge there, instead of modifying other parts of the codebase |
| 03:56.05 | radix | ok good night |
| 04:11.17 | tjs | does storm use __setstate__ and __getstate__ ? |
| 04:51.37 | tjs | oh interesting |
| 04:51.54 | tjs | failed transactions with inserts still consume auto-incrementing key ids |
| 04:51.57 | tjs | in mysql |
| 04:53.32 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 05:28.45 | tjs | 3 |
| 05:28.50 | tjs | oops |
| 06:25.04 | weatherman | storm/store-name r171 committed by jkakar@kakar.ca |
| 06:25.04 | weatherman | - Moved the store name retrieval functionality entirely into ZStorm, |
| 06:25.05 | weatherman | <PROTECTED> |
| 06:25.09 | weatherman | <PROTECTED> |
| 06:25.13 | weatherman | - Removed Store.name and updated relevant tests. |
| 06:29.17 | jkakar | tjs: I've implemented the changes radix recommended; their pushed up if you want them. |
| 06:29.36 | jkakar | they're, even. |
| 06:31.04 | tjs | ty |
| 06:31.08 | tjs | quick q |
| 06:31.36 | tjs | if I have a Foo class with an attr like flibble = Int() |
| 06:31.48 | tjs | then I subclass Foo to Bar |
| 06:32.49 | tjs | could I say store.find(Bar, Foo.flibble == 3456) |
| 06:33.38 | tjs | er, sec, perhaps I'm being confused by what I need to do |
| 06:33.43 | tjs | argh |
| 06:34.07 | tjs | jkakar: mind being a sounding board? |
| 06:34.50 | jkakar | tjs: 'sup? |
| 06:35.01 | tjs | so I have crossref.SCrossref which is a descriptor, and it takes a list of classes that it can keep references to |
| 06:35.16 | jkakar | Okay. |
| 06:35.29 | tjs | so that given the key to lookup ("STORM", ("CLASSNAME",... |
| 06:35.35 | jkakar | uh huh |
| 06:35.40 | tjs | it can find the class with that name, then use it to do a search |
| 06:35.58 | jkakar | Do you pass in that key with the list of classes during instantiation? |
| 06:36.16 | jkakar | er, key/class in the list I guess. |
| 06:36.35 | tjs | the IHaveReferences implementation for the storm backend takes the list of classes with the key, yep |
| 06:36.41 | tjs | to construct the query |
| 06:37.02 | tjs | store.find(klass, getattr(klass, key[1]) == key[2]).one() |
| 06:37.20 | jkakar | Okay, I'm with you. |
| 06:37.52 | tjs | ok, so classes get passed to the descriptor, I didn't think this was that bad/ugly |
| 06:38.19 | tjs | but now in implementing zope-friendly objects I need to support keeping a __parent__ reference on each object |
| 06:38.25 | jkakar | Yeah, that seems to make sense. How else would the descriptor learn about them? |
| 06:38.52 | jkakar | What's a __parent__ reference? I use Zope, but we don't use any of it's container-y folder-y stuff. |
| 06:39.20 | tjs | a __parent__ attribute on any object just holds the parent object |
| 06:39.47 | tjs | I can easily make my objects have __parent__ = crossref.SCrossref() |
| 06:40.02 | tjs | but then things need to know what classes they may be contained by |
| 06:40.08 | tjs | which is getting pretty ugly |
| 06:40.21 | jkakar | Right. |
| 06:40.35 | jkakar | Do the objects in the SCrossref already have valid __parent__'s? |
| 06:41.06 | tjs | perhaps, I guess, they might be other instances of this same class |
| 06:41.25 | jkakar | ie: Is there a way you can proxy that data via some API on SCrossref? |
| 06:41.43 | tjs | not without pulling the object out of the db |
| 06:41.49 | tjs | I dont think.. |
| 06:41.51 | jkakar | I'm not sure I entirely understand what kind of classes go in an SCrossref. |
| 06:42.05 | jkakar | It's arbitrary, right? |
| 06:42.10 | tjs | any class that implements IReferenceable |
| 06:42.12 | tjs | but yeh |
| 06:42.24 | tjs | so I was thinking |
| 06:42.35 | tjs | jkakar: its in my code |
| 06:42.45 | jkakar | tjs: Oh. :) |
| 06:42.51 | tjs | it just defines a getKey method |
| 06:43.02 | tjs | that returns the key to be stored for that object as the reference |
| 06:43.08 | jkakar | Ah, I see. |
| 06:43.21 | jkakar | The key you use to construct queries with. |
| 06:43.26 | tjs | yes |
| 06:44.22 | jkakar | So I guess you want __parent__ to be a lazy-loaded property. At least, behaviour-wise. |
| 06:44.31 | tjs | yeh |
| 06:44.32 | jkakar | ie: Don't touch the DB until you absolutely have to. |
| 06:44.58 | jkakar | What kind of API does SCrossref have? |
| 06:45.21 | jkakar | ie: Is it like a Reference in Storm? |
| 06:45.28 | tjs | just trying to think of a way to not need all objects to define their own __parent__ and pass it the types of folders they may be contained in |
| 06:45.30 | jkakar | I guess it has basically the same purpose. |
| 06:45.37 | tjs | yeh |
| 06:46.17 | tjs | so if I had a BaseStormFolder class (because all __parents__ would be pointed at a folder of some type) |
| 06:46.41 | jkakar | I see. |
| 06:47.36 | tjs | could I just say, store.find(BaseStormFolder, BaseStormFolder.id == 123) and somehow get an object that was a subclass of BaseStormFolder |
| 06:47.56 | tjs | if all folders are stored in the same table |
| 06:48.33 | tjs | or do I really need to have the class available to me |
| 06:48.42 | jkakar | why wouldn't you just do store.find(SubclassedStormFolder, SubclassesStormFolder.id == 123)? |
| 06:48.53 | jkakar | Where SubclassesStormFolder would leave __storm_table__ untouched, I guess. |
| 06:49.04 | jkakar | brb |
| 06:49.09 | tjs | because to do that I'd need to know what Classes something might be contained in |
| 06:49.22 | tjs | which gets back to the ugly bit |
| 06:54.12 | tjs | I could make the base class have a metaclass that keeps a list of all its subclasses |
| 06:54.48 | tjs | so that given the base class, I could get a list of all possible subclasses, and then check those against the class name in the key being looked up, |
| 06:55.04 | tjs | and then use that class object to construct my query |
| 06:55.08 | tjs | urgh |
| 07:06.24 | jkakar | That sounds like a crappy problem. :( |
| 07:06.47 | jkakar | There was something in storm that would have done that for you. |
| 07:09.35 | tjs | what is that? |
| 07:11.11 | weatherman | storm/store-name r172 committed by jkakar@kakar.ca |
| 07:11.11 | weatherman | - Added missing test and functionality to clean up internal |
| 07:11.12 | weatherman | <PROTECTED> |
| 07:11.36 | jkakar | tjs: There was an adaptation thing where you could use tricks to make the kind of thing you're describing work. It was confusing. :) |
| 07:11.51 | jkakar | tjs: It was removed some time ago now. |
| 07:12.23 | tjs | considering it took me 10 minutes to phrase my question so it could be understood, I'm not supprised the solution is a confusing one ;) |
| 07:13.04 | jkakar | Heh |
| 07:13.34 | jkakar | tjs: I'm wondering about a solution where you register "context" objects and then look them up (with getMultiAdapter) when you need them. |
| 07:13.59 | jkakar | You could provide some ZCML glue to make it possible to define the relationships you need as configuration. |
| 07:14.05 | tjs | yeh |
| 07:14.46 | jkakar | We've used that pattern for a variety of things where we need to store some thing (like a URL) for a something else which doesn't care about that thing (like a model object). |
| 07:15.39 | tjs | ah |
| 07:15.41 | jkakar | tjs: I need to sleep now... if I have a brainwave about your problem I'll let you know. Have a good one. Also, pushed some new revisions on the store-name branch. |
| 07:16.09 | tjs | night :) |
| 07:16.11 | tjs | thanks :) |
| 07:16.16 | tjs | home time for me also |
| 07:33.43 | *** join/#storm michele (n=michele@ip-132-247.sn2.eutelia.it) |
| 09:36.09 | *** join/#storm desmaj` (n=user@d65h163.public.uconn.edu) |
| 09:55.00 | *** join/#storm michele_ (n=michele@ip-132-247.sn2.eutelia.it) |
| 11:09.16 | *** join/#storm desmaj`` (n=user@d65h163.public.uconn.edu) |
| 11:14.57 | *** join/#storm niemeyer (n=niemeyer@201-14-38-86.ctame705.dsl.brasiltelecom.net.br) |
| 12:25.45 | *** join/#storm nephish_ (n=piv@63.98.191.58) |
| 12:30.29 | *** join/#storm jukart (n=jukart@bas12-toronto12-1096759377.dsl.bell.ca) |
| 12:30.29 | nephish_ | hey gents, trying to install the new version and i get this from easy install : No local packages or download links found for storm==0.10 |
| 12:30.40 | nephish_ | best to go with a different means of installation ? |
| 12:30.59 | nephish_ | oh, using the egg, btw |
| 12:33.24 | niemeyer | nephish_: Yeah, we haven't found a way to please setuptools yet |
| 12:34.14 | nephish_ | ok, should i just grab the tarball ? |
| 12:37.35 | michele_ | easy_install -f https://launchpad.net/storm/+download |
| 12:37.43 | michele_ | should work I think |
| 12:38.43 | michele_ | easy_install -f https://launchpad.net/storm/+download storm |
| 12:38.43 | niemeyer | michele_: Ah, that's nice |
| 12:38.57 | michele_ | I forgto storm at then end :-) |
| 12:39.00 | michele_ | forgot |
| 12:39.04 | niemeyer | michele_: Do you know if there's some metadata we can add to setup.py to make that the default? |
| 12:39.29 | michele_ | mmm the only thing you can do is publish it on the cheeseshop |
| 12:39.38 | michele_ | or is there already? |
| 12:39.55 | niemeyer | It's there already |
| 12:40.00 | niemeyer | But it looks only in the web page |
| 12:40.17 | niemeyer | I'd love a way to say "hey, easy_install, files are at http://..." |
| 12:40.31 | michele_ | you can add find_links on your setup.py but it just works for your dependencies |
| 12:41.00 | michele_ | I'm pretty sure there is a way to tell setuptools to automatically look up into your launchpad page :-/ |
| 12:41.54 | michele_ | the storm page on cheeseshop |
| 12:42.09 | michele_ | doesn't provide a download url |
| 12:42.13 | niemeyer | michele_: Ah, you got it I think |
| 12:42.29 | michele_ | you must put a download url that's just https://launchpad.net/storm/+download |
| 12:42.34 | michele_ | and it will works nicely I guess |
| 12:42.35 | nephish_ | mmm, it just tried to remove 0.10 and install .9 |
| 12:42.51 | nephish_ | said it was the best match |
| 12:43.55 | michele_ | niemeyer: can you edit http://cheeseshop.python.org/pypi/storm/? |
| 12:44.02 | michele_ | is there a web ui? |
| 12:45.05 | niemeyer | michele_: I think so.. |
| 12:47.00 | niemeyer | Hmm |
| 12:47.49 | niemeyer | There's a Download URL thing in the PKG-INFO |
| 12:48.00 | niemeyer | I just have to find out where it's extracted from |
| 12:49.02 | niemeyer | Duh.. download_url |
| 12:49.16 | michele_ | http://docs.python.org/dist/meta-data.html |
| 12:49.19 | michele_ | yep |
| 12:49.20 | michele_ | ;-) |
| 12:50.26 | niemeyer | michele_: Can you check out if it works for you now? |
| 12:50.59 | michele_ | sure |
| 12:51.45 | michele_ | works like a charm :-) |
| 12:51.57 | michele_ | $ easy_install storm |
| 12:52.19 | michele_ | Best match: storm 0.10 |
| 12:52.19 | michele_ | Downloading https://launchpad.net/storm/trunk/0.10/+download/storm-0.10-py2.4.egg |
| 12:52.44 | niemeyer | Woot! |
| 12:52.47 | niemeyer | michele_: Thanks! |
| 12:53.16 | michele_ | thanks to you :-) |
| 12:54.34 | michele_ | btw, tnx for the quick fix regarding the isolation level, looks very good |
| 12:55.33 | niemeyer | You're welcome |
| 12:55.35 | michele_ | it will help me introduce storm in our own toolbox, here at work |
| 12:55.51 | nephish_ | the python2.4 egg still downloads and installs 2.5 |
| 12:56.30 | michele_ | nephish_: strange I'm on py2.4 here and it downloads the right one |
| 12:56.50 | michele_ | let me try with py2.5 |
| 12:57.37 | nephish_ | does it check which python version you are actually using before the download ? |
| 12:58.24 | nephish_ | i am on my dev/test box, my server runs 2.4 ( ubuntu 6.10 ) my test box is 2.5 (ubuntu 7.4) |
| 12:58.38 | michele_ | I'm on feisty |
| 12:58.50 | michele_ | but I use py2.4 since we deploy to dapper |
| 12:59.04 | michele_ | I use workingenv.py to create isolate environments |
| 12:59.24 | michele_ | I just created a py2.5 env and easy_install uses the py2.5 egg |
| 12:59.25 | weatherman | storm/trunk r170 committed by gustavo@niemeyer.net |
| 12:59.25 | weatherman | Added download_url to setup.py, to please easy_install when harvesting |
| 12:59.26 | weatherman | information on CheeseShop. Thanks to Michele Cella for helping out. |
| 12:59.59 | michele_ | Best match: storm 0.10 |
| 12:59.59 | michele_ | Downloading https://launchpad.net/storm/trunk/0.10/+download/storm-0.10-py2.5.egg |
| 12:59.59 | michele_ | Processing storm-0.10-py2.5.egg |
| 13:00.38 | michele_ | nephish_: ls -al /usr/bin/python gives you? |
| 13:00.38 | nephish_ | oh, then i should be ok on the server. |
| 13:01.20 | nephish_ | test / dev box : lrwxrwxrwx 1 root root 9 2007-05-28 11:40 /usr/bin/python -> python2.5 |
| 13:01.23 | michele_ | ok, easy_install searches for the egg that uses the same python version that's executing it |
| 13:01.59 | nephish_ | server lrwxrwxrwx 1 root root 9 2006-12-15 12:55 /usr/bin/python -> python2.4 |
| 13:02.04 | nephish_ | ok, i should be ok then |
| 13:02.05 | michele_ | yep |
| 13:02.10 | michele_ | yes, think so |
| 13:02.36 | michele_ | http://cheeseshop.python.org/pypi/workingenv.py |
| 13:02.46 | michele_ | that's very useful |
| 13:02.55 | michele_ | if you didn't know about it ;-) |
| 13:03.01 | michele_ | maybe you're using it already anyway... |
| 13:13.14 | mcella | niemeyer: any plan to support single table inheritance? |
| 13:14.29 | niemeyer | mcella: Support in what sense? |
| 13:14.57 | mcella | well, I guess it's going to be pretty simple given storm architecture |
| 13:15.27 | mcella | basically you map a set of classes into one table |
| 13:15.46 | mcella | and distinguish between them using a type attribute |
| 13:15.59 | mcella | type column sorry |
| 13:16.13 | niemeyer | mcella: Ah, that kind, ok |
| 13:16.22 | niemeyer | mcella: There's a funny story about that |
| 13:16.32 | mcella | http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html |
| 13:16.33 | niemeyer | mcella: Storm already supported something along these lines in the past |
| 13:16.49 | nephish_ | ok, installed on main server, but i don't think it downloaded anything. http://paste.pocoo.org/show/2313/ |
| 13:17.11 | niemeyer | mcella: We have precisely that pattern in Landscape, where we use Storm |
| 13:17.17 | niemeyer | mcella: But.. |
| 13:17.23 | niemeyer | mcella: (there's always a but :-) |
| 13:17.28 | mcella | niemeyer: :-) |
| 13:17.47 | mcella | nephish_: no download since you passed the egg directly to easy_install |
| 13:17.47 | niemeyer | mcella: The application code ended up being a mess |
| 13:18.19 | niemeyer | mcella: And after a while, we decided to refactor the code into a model which reflected what was in the database |
| 13:18.28 | niemeyer | mcella: and there was rejoicing ;) |
| 13:18.39 | niemeyer | mcella: So.. |
| 13:18.54 | niemeyer | mcella: The support in Storm was removed *just* before turning it public :-) |
| 13:19.15 | niemeyer | mcella: Because we're not sure if it's a good idea to do so, and didn't want to support a crappy feature. |
| 13:19.19 | mcella | niemeyer: good to know, I was going to give it a try someday :-D |
| 13:19.29 | niemeyer | mcella: Well.. you may have success.. |
| 13:19.35 | niemeyer | mcella: Don't give up.. :) |
| 13:19.36 | mcella | activerecord supports it, sqlalchemy also |
| 13:19.43 | mcella | but... |
| 13:19.45 | mcella | :-D |
| 13:20.06 | niemeyer | mcella: But we couldn't make it clean, and all the "smartness" turned out to be a pain in practice |
| 13:20.25 | mcella | I just discovered this since I'm working on a table (designed by someone else) where I would need something like this |
| 13:20.33 | mcella | with my home made orm |
| 13:20.34 | niemeyer | Today we still have the code, and it's a pretty involved relationship, but everyone understands it |
| 13:20.42 | nephish_ | mcella_: sorry, so i am all good here then ? |
| 13:20.48 | mcella | nephish_: yep |
| 13:20.56 | nephish_ | great !, thx |
| 13:21.35 | mcella | niemeyer: yep, maybe it's just a bad design choice mapping more classes into the same table |
| 13:21.41 | niemeyer | mcella: Btw, you may be interested in that document: http://www.agiledata.org/essays/mappingObjects.html |
| 13:21.49 | niemeyer | mcella: It's a more comprehensive version of these idas |
| 13:21.50 | niemeyer | ideas |
| 13:22.04 | mcella | niemeyer: tnx |
| 13:22.55 | mcella | nephish_: for storm 0.11 you just need |
| 13:23.00 | mcella | sudo easy_install -U storm |
| 13:23.07 | mcella | or |
| 13:23.16 | mcella | sudo easy_install storm==0.11 |
| 13:23.25 | mcella | when 0.11 is out obviously ;-) |
| 13:23.30 | niemeyer | mcella: Well, in some cases it's a good idea to do the mapping.. |
| 13:23.49 | niemeyer | mcella: We still have the same schema design we had before.. what changed was the way we reflect it on Storm |
| 13:23.53 | nephish_ | mcella_: i am writing that down, thanks |
| 13:23.56 | mcella | niemeyer: hey, that's a pretty good link... tnx :-) |
| 13:23.58 | radix | jkakar: thanks for doing the Fixed Releases :) |
| 13:24.03 | radix | morning guys! |
| 13:24.17 | mcella | morning radix :-) |
| 13:24.21 | niemeyer | mcella: np :) |
| 13:24.30 | niemeyer | radix: Morning! |
| 13:25.06 | mcella | niemeyer: I'm going to push storm here, atm we are using a custom orm (50 lines of code) that just maps every row into an object |
| 13:25.15 | mcella | and ZODB for other things |
| 13:25.36 | mcella | ideally we would like to switch everything to storm |
| 13:26.13 | radix | awesome |
| 13:26.17 | mcella | Zodb is pretty cool, but there are problems related to the inaccessibility of it's data (for reporting purpose for example) |
| 13:28.33 | mcella | niemeyer: just curious, how are you reflecting that schema into storm now? |
| 13:31.13 | mcella | now that I think more about it, you can already achieve single table inheritance with storm... you just need a different class that keeps the same __storm_table__ |
| 13:35.48 | radix | yeah, we've done something like that |
| 13:36.32 | mcella | yep, you don't need a magic attribute since you usually tell the store what object you want to retrieve |
| 13:36.49 | radix | right, there's always a type explicitly referenced somewhere |
| 13:36.54 | radix | in a store.find, or a ReferenceSet, or whatever |
| 13:37.07 | mcella | yep, that's cool and pythonic ;-) |
| 13:38.00 | niemeyer | and simple, which makes our poor human brains thankful |
| 13:38.10 | mcella | right :-) |
| 14:07.38 | *** join/#storm desmaj (n=user@d65h163.public.uconn.edu) |
| 14:29.57 | *** join/#storm bigdog (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 16:53.12 | *** join/#storm jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 16:53.12 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.10 released! || Review branches: https://bugs.launchpad.net/storm/+bugs?field.tag=review |
| 17:39.22 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) |
| 18:31.17 | *** join/#storm jdahlin (n=jdahlin@201-27-6-221.dsl.telesp.net.br) |
| 18:31.30 | jdahlin | congrats for the new release radix & niemeyer |
| 18:31.36 | jdahlin | and thanks for applying my patches |
| 18:31.41 | radix | thanks, sure thing |
| 18:43.04 | jdahlin | and there, my evil hack shows up on the mailing list |
| 19:16.21 | mcella | hey guys |
| 19:16.31 | mcella | can I ask a question regarding storm internals? .-/ |
| 19:18.19 | niemeyer | mcella: Heya |
| 19:18.21 | niemeyer | Sure thing |
| 19:18.44 | mcella | ok, what's the mechanism behind |
| 19:18.53 | mcella | MyClass.attribute = value |
| 19:19.16 | mcella | becoming a storm.expr.Expr instance? |
| 19:19.24 | niemeyer | mcella: Hmm.. I guess you probably mean something else.. nothing is done about that kind of assignment |
| 19:19.24 | mcella | MyClass.attribute == value |
| 19:19.28 | niemeyer | mcella: Ah, ok |
| 19:19.33 | mcella | yep ;-) |
| 19:19.43 | niemeyer | mcella: Python descriptors |
| 19:19.59 | niemeyer | mcella: http://docs.python.org/ref/descriptors.html |
| 19:20.12 | mcella | ah, stupid me! :-) |
| 19:20.27 | mcella | yep, it's triggered by the attribute descriptor |
| 19:20.32 | mcella | Unicode, Int... |
| 19:20.33 | niemeyer | Yep |
| 19:21.02 | mcella | cool, sorry for the dumb question :-) |
| 19:21.17 | mcella | it's been a long day :-D |
| 19:21.18 | niemeyer | No worries.. |
| 19:21.32 | mcella | ok, another question... :-P |
| 19:21.53 | mcella | I'm experimenting a little bit with a little feature that could be nice (IMHO) |
| 19:22.31 | mcella | is get_where_for_args used by everything that needs to query for a given object? |
| 19:24.02 | niemeyer | Hmm |
| 19:24.14 | niemeyer | I don't think so |
| 19:24.21 | niemeyer | There are many ways to get an object |
| 19:24.35 | niemeyer | Well |
| 19:24.39 | niemeyer | Maybe it is, depending on what you mean |
| 19:24.54 | niemeyer | What was the idea? |
| 19:25.18 | mcella | well, it has to be with the single table inheritance thing I was talking about today |
| 19:25.20 | mcella | :-D |
| 19:25.52 | mcella | it's just a very easy mechanism that let's you add additional where clauses bounded to an object |
| 19:26.13 | mcella | let me show you a pastebin... |
| 19:26.20 | mcella | of the concept |
| 19:27.03 | niemeyer | I guess I understand |
| 19:27.14 | niemeyer | But how do you use it in complex queries? |
| 19:27.59 | niemeyer | E.g. joins |
| 19:28.27 | mcella | http://paste.pocoo.org/show/2323/ |
| 19:28.52 | mcella | well, it's just a crazy idea |
| 19:29.03 | mcella | I dunno if it could work out with more complex queries |
| 19:29.32 | niemeyer | The "where" would probably have to be matched on the python side |
| 19:29.51 | mcella | The example I'm showing you is working here |
| 19:30.06 | mcella | the idea is just that every thing you list in __storm_where__ |
| 19:30.32 | mcella | is added to the where clause of every query involving that object |
| 19:30.43 | niemeyer | Right, I think that won't work on joins |
| 19:31.10 | mcella | yep, me too :-) |
| 19:32.13 | mcella | I have a limited vision, since I've looked at storm sources very briefly |
| 19:32.32 | niemeyer | mcella: What do you think of a __storm_adapt__() method on Player which allowed you to return a different type? |
| 19:33.31 | mcella | well, the idea is not returning a different type |
| 19:34.03 | radix | the axiom guys have this idea about statically declaring queries |
| 19:34.07 | radix | only vaguely related |
| 19:34.28 | mcella | yep, the concept is like a static filter |
| 19:34.30 | radix | their main idea is to take the declaration of the queries as a way to help them generate an efficient schema |
| 19:34.32 | niemeyer | mcella: That's what I told you about, that we used to have |
| 19:35.06 | radix | hmm |
| 19:35.19 | niemeyer | radix: Hmm.. like a precompiled query? |
| 19:35.21 | radix | niemeyer: I don't think he's exactly trying to get at the same thing that __storm_adapt__ did, given that all of the data is in the same table |
| 19:35.26 | radix | niemeyer: yes, like a precompiled query |
| 19:35.28 | mcella | yep, radix |
| 19:35.37 | niemeyer | radix: Our data with __storm_adapt__ was also in the same table |
| 19:35.39 | mcella | the concept is not adapting the object |
| 19:35.39 | radix | niemeyer: their idea was to look at these precompiled queries to find out which indexes should be defined |
| 19:35.50 | niemeyer | radix: Well, some of it, at least |
| 19:35.54 | radix | niemeyer: most of the time the thing returned from __storm_adapt__ was an object from a different table, though |
| 19:35.58 | mcella | is filter only the rows related to the object |
| 19:36.07 | niemeyer | radix: Indeed |
| 19:37.04 | mcella | brb |
| 19:37.26 | niemeyer | radix: Yeah, you're right, it's kind of the opposite way |
| 19:37.43 | niemeyer | find() happens on the subclass |
| 19:37.51 | niemeyer | and the subclass shares table with the parent |
| 19:38.17 | mcella | and any other subclass |
| 19:38.26 | mcella | so if you do find(Subclass) |
| 19:38.41 | mcella | you're going to get results regarding other subclasses |
| 19:38.55 | mcella | with __storm_where__ you can say |
| 19:39.07 | mcella | what distinguish a subclass from another |
| 19:39.19 | mcella | this in the case of single table inheritance |
| 19:39.32 | mcella | but the mechanism is not bound to it |
| 19:39.57 | mcella | you could define other "static filters" |
| 19:40.18 | mcella | my idea is to let __storm_where__ be any instance of Expr |
| 19:40.38 | mcella | so you can even define complex requirements and compile them down to SQL |
| 19:40.54 | mcella | but I dunno if it is feasible :-) |
| 19:41.32 | mcella | I just experimented a bit, just 4 fun ;-) |
| 19:43.13 | niemeyer | Right, that's good :) |
| 19:46.31 | mcella | http://paste.pocoo.org/show/2327/ |
| 19:46.51 | mcella | that's it ;-) |
| 19:52.50 | mcella | well, need to go guys |
| 19:53.21 | mcella | maybe I will come back with something working some(far away)day :-D |
| 19:53.32 | mcella | bye and tnx |
| 21:29.23 | *** join/#storm BleSS (n=BleSS@227.Red-83-38-46.dynamicIP.rima-tde.net) |
| 21:29.30 | BleSS | hi all |
| 21:30.10 | jkakar | Heya BleSS |
| 21:30.16 | BleSS | I want to say anything about the license. It looks very well that been LGPL |
| 21:30.29 | jkakar | Cool |
| 21:31.12 | BleSS | but when you indicate the version then if any user is going to create to a project GPL or LGPL |
| 21:31.24 | BleSS | is limited to use GPL 2.0 or LGPL 2.1 |
| 21:31.46 | BleSS | he cann't use GPL/LGPL 3.0 |
| 21:32.29 | BleSS | i think that the best would not indicate the version so the user has not that problem |
| 21:38.44 | ajmitch | the code has " either version 2.1 of the License, or (at your option) any later version." |
| 21:40.52 | BleSS | ah, ok, but in the main page says: |
| 21:40.56 | BleSS | Storm is licensed under the [WWW] LGPL 2.1. |
| 21:41.20 | BleSS | s[/WWW]// |
| 21:42.27 | ajmitch | which is still quite true, but the headers in the source fiels allow use of a newer LGPL, from what I've seen :) |
| 21:43.52 | BleSS | cool :) |
| 21:48.18 | jkakar | BleSS: If you want to see the exact wording you can find the entire license in the LICENSE file that comes with Storm. |
| 21:49.07 | BleSS | yes, there is not problem |
| 21:50.23 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 21:53.44 | *** part/#storm BleSS (n=BleSS@227.Red-83-38-46.dynamicIP.rima-tde.net) |
| 22:15.26 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 23:17.48 | tjs | jkakar: one of the guys here came up with a since solution for that needing-the-class issue we discussed |
| 23:17.51 | tjs | http://rafb.net/p/d0ozMH62.html |
| 23:18.02 | tjs | s/since/nice |
| 23:18.44 | jkakar | tjs: Ah, very nice. |
| 23:18.59 | jkakar | tjs: My brain still doesn't naturally think of metaclasses. :) |
| 23:19.11 | tjs | :) |
| 23:19.31 | jkakar | tjs: But I often see them and realize how they can be simple solutions in certain situations. |
| 23:19.51 | jkakar | tjs: What time of day is it for you now? |
| 23:20.11 | tjs | 9:18am |
| 23:21.55 | tjs | jkakar: the cool thing is that because all of these classes will have a <class> zcml entry, they will all be loaded at runtime and thus all be available, don't need to go hunting for them all to import |
| 23:22.18 | tjs | zomgosh, zcml actually providing something useful?! |
| 23:22.18 | jkakar | tjs: Ah, very nice. |
| 23:23.03 | jkakar | tjs: Hehe. Other than the usual complaints about how verbose it is I generally enjoy ZCML. |
| 23:38.37 | *** join/#storm jml (n=jml@ppp121-44-223-194.lns1.hba1.internode.on.net) |
| 23:46.20 | radix | oi. |
| 23:46.30 | radix | bless is confused :( |
| 23:49.58 | *** join/#storm nephish_ (n=nephish@69.55.30.106) |
| 23:50.49 | nephish_ | hello all |