IRC log for 2008-02-26
1 view
Skip to first unread message
David Leal
Feb 26, 2008, 7:05:01 PM2/26/08
to datam...@googlegroups.com
--- Log opened Tue Feb 26 00:00:18 2008
00:00 < dkubb> is the idea with DO to cast the data to a default ruby type based on the column type, unless another type is specified?
00:01 < RailsAddict> dkubb: no, that's just what RbMysql is doing at the moment.
00:01 < RailsAddict> the idea is to use the property :name, :type => String declarations
00:03 < dkubb> ahh, so by default alot of stuff will come out as a String unless someone specifies the property :type
00:03 < RailsAddict> DO will pass an array of types to the Reader, and the reader will cast each value based on that array.
00:04 < bernerdschaefer_> Well, property declarations always require a :type, so inside DM the types will be set by #set_types
00:05 < RailsAddict> yup
00:05 < bernerdschaefer_> Presumably, though, there could be an instance where you just want DO to load a row directly from the column types
00:07 < bernerdschaefer_> And that means DM will be doing almost no type casting -- it will all happen in C on the driver side
00:07 < bernerdschaefer_> Which is Cool(tm)
00:08 < RailsAddict> bernerdschaefer_: would it be wise to work on a shared library that we could use to handle date parsing and such?
00:08 < RailsAddict> do_fast_date_parse(char *) or the like
00:08 < bernerdschaefer_> Probably so. I thought about that
00:09 < RailsAddict> its really only those 3 methods though, date, time, datetime
00:10 < RailsAddict> and mysql just gives me an array or strings, whereas it looks like the sqlite driver gives you strings/ints/longs, etc.
00:11 < bernerdschaefer_> Yeah. The only part that feels weird just copy/pasting is the math stuff for generating the time fractions
00:12 < bernerdschaefer_> I do feel that we should coordinate on the function names, though... Maybe share a .h file with the #defines and the basic api?
00:13 < bernerdschaefer_> Or maybe not. Maybe just make sure they're all the same
00:14 < RailsAddict> Dunno man. I wish I could work on this stuff right now...
00:15 < RailsAddict> The libraries aren't that big right now, and I can't see them getting much larger method-wise.
00:15 < bernerdschaefer_> Yeah
00:16 < RailsAddict> unfortunately the only time I get to work on this stuff is early in the morning, when all sane people are snoozing.
00:16 < bernerdschaefer_> heh
00:24 < dkubb> how do you make a decimal property, and specify it precision and scale?
03:10 < afrench> anyone alive?
03:11 < bernerdschaefer_> Sort of
03:12 < afrench> you bernerd
03:12 < afrench> yo*
03:12 < bernerdschaefer_> wazza?
03:12 < afrench> watchin' the game, having a bud.....you?
03:13 < bernerdschaefer_> watchin' the game... havin' a bud. You?
03:13 < bernerdschaefer_> (PS, I love you man!)
03:13 < afrench> hold on.....HEY DOOKIE
03:14 < afrench> PICK UP THE PHONE
03:14 < dookie> Waaaaaasssssuuuuppppppp
03:14 < bernerdschaefer_> Man. The old days. When commercials that sucked sucked funnily
03:14 < afrench> totally
03:14 < bernerdschaefer_> (I know that's not a word, but I like it)
03:15 < kenphused> omg... i just saw a dallas mav cheerleader i would write bad checks for
03:15 < bernerdschaefer_> heh
03:16 < afrench> "I would bounce-checks for you".....now _that's_ a pick-up line
03:16 < kenphused> lol
03:22 < afrench> has anyone used Validatable's Group Validations (or contextual validations) with DM yet?
03:22 < bernerdschaefer_> You?
03:22 < afrench> was thinking about it pretty hard the other day
03:22 < afrench> http://adam.speaksoutofturn.com/archives/51
03:22 < afrench> and I'm thinking DM doesn't really effectively support it
03:23 < afrench> I had to overload save() so that I could pass it which group of validations to test against
03:23 < bernerdschaefer_> I saw that
03:23 < afrench> I shouldn't have to do that, right?
03:24 < bernerdschaefer_> Don't know. It does looks suspiciously hard to do, given that we include Validateable by default
03:24 < afrench> how do you mean?
03:24 < afrench> oh oh, sorry, yeah
03:27 < afrench> really seems like .save() should take a :group from validatable
03:30 < bernerdschaefer_> Yeah. Though, I suppose that would be easy enough to add into /lib on DM::Persistence
03:30 < bernerdschaefer_> But it would be nice to add and then, you know, brag about the feature
03:31 < afrench> default it to :save, probably
03:32 < bernerdschaefer_> brb, got to walk down to the PDK and get some cigarettes
03:32 < afrench> pdk?
03:32 < bernerdschaefer_> Pretty Darn Kwik? I dunno. The convenience store across from campus
03:33 < afrench> aah, gotcha
03:57 < pius> hi everyone
03:58 < pius> does anyone have a best practice approach for loading seed data? I'm suffering a bit under the destructive migrations ;)
04:07 < afrench> seed data for development?
04:08 < pius> yup
04:08 < afrench> rspec mocks and stubs aren't enough?
04:08 < pius> I'll need to do it for prod later as well
04:09 < pius> for dev, that would be enough
04:09 < pius> but not for prod
04:09 < pius> (obviously)
04:10 < afrench> there's a fixtures method in the spec-helper for datamapper that's _really_ handy
04:10 < afrench> I don't think its part of the public API, but your more than welcome to it
04:11 < pius> ah, cool
04:44 < myobie> pius: i just used the Faker gem today and a rake task to load up 20000 random records
04:45 < pius> myobie: I forgot about faker! Thanks a bunch. :)
05:29 < dkubb> ssmoot: Looks like there is a syntax error at line 125 of do_sqlite3/lib/do_sqlite3.rb: http://github.com/sam/do/commit/48f265d364c91d84456a1a57c6515bb026f3c343 (the inspect method was added without its own end tag)
10:29 < argv[]> http://yard.soen.ca/docs/datamapper-0.3.0/diagram.png
10:30 < argv[]> wee
10:55 < ior3k> Rando: ping?
14:56 < ior3k> Rando: ping?
15:56 < SuprNoodles> what's the best way to get 'acts_as_list' type functionality into datamapper? should I just write my own stuff to get it? or is there a plugin someone can recommend?
16:55 < Rando> ior3k: pong
17:31 < SuprNoodles> is there a datamapper plugin for acts_as_list?
17:33 < afrench> SuprNoodles: check out is_a_list
17:38 < SuprNoodles> thanks afrench - checking it out now
17:38 < afrench> I haven't used it, personally, but I've seen it and seen commits on it
17:44 < SuprNoodles> afrench: is it on git-hub?
17:45 < afrench> not super sure....I think it's in dm/ somewheres
17:46 < bernerdschaefer> I think there's only is_a_tree
17:47 < afrench> it's in /lib/data_mapper/is/tree.rb
17:48 < Rando> ssmoot: ping
17:50 < ssmoot> Rando: I live-eth.
17:51 < Rando> when you're setting up a model class, how do you specify which adapter it should use?
17:56 < Rando> class Person; repository = :foo_repo; end
17:56 < Rando> ?
17:59 < ssmoot> Rando: right now you don't. The model will just map to any repository with it's default attributes.
18:00 < ssmoot> Rando: let me pastie something real quick.
18:00 < Rando> ok
18:08 * ssmoot pasted http://pastie.textmate.org/private/bmpht5kp714aaajd2mxa
18:08 < ssmoot> Rando: ^^^
18:10 < ssmoot> Rando: I meant to write pseudo-code, but I think that may actually be very close to the actual implementation. ;) Except that DataMapper::Container would set the class-ivars of course, and they'd probably need to be accessed through methods so they could handle derived classes as well for inheritance.
18:10 * ssmoot is bouncing around the office this morning, but I'll keep abreast of the convo. :)
18:11 < Rando> ssmoot: np
18:13 < bernerdschaefer> Hmm.. Anyone tried installing ruby 1.9 from the svn tag?
18:14 < bernerdschaefer> Er.. hm. Nevermind
18:16 < Rando> ssmoot: whats the need for the cross-repo feature of models? Seems like quite a bit of extra work for something that would get used pretty rarely, if at all
18:16 < bernerdschaefer> Sweet. YARV, 1.9, Rubinius are all set up.. now time to run to class!
18:25 < ssmoot> Rando: because it's cool. :) And easy. And we need it at Wieck.
18:26 < ssmoot> Rando: and by 0.9.0 we hope to have a YamlAdapter to replace fixtures. So it'll get used by pretty much everyone...
18:26 < ssmoot> Everyone who uses fixtures now in their tests anyways. ;)
18:26 < Rando> ssmoot: ah, right
18:26 < Rando> not me, fixtures are a PITA
18:27 < ssmoot> Which is a good argument for mapping any repo with defaults actually vs always mapping explicitly since it would just be a pain to have to opt-in every model to your fixtures repo.
18:29 < Rando> ssmoot: i mean the cross-repo stuff; different properties based on the repo
18:38 < ior3k> ssmoot: ping?
18:48 < ior3k> Rando: ping?
18:49 < Rando> ior3k: yo
18:49 < ior3k> hey
18:49 < ior3k> I have a few ideas and a few doubts about the organizational changes
18:50 < Rando> ior3k: welcome to the club :)
18:50 < ior3k> Rando: lol
18:50 < ior3k> Rando: so what's the status on the whole thing? Does the wiki count?
18:50 < Rando> sorta
18:51 < ior3k> is the mapping branch kind of experimental, or is it supposed to be the definitive implementation?
18:51 < Rando> the only official spec is in sam's head. I've gleaned quite a bit from him in irc over the last few weeks, and some of that is in the wiki
18:52 < Rando> its about 1/3 of where we want to go with it, i tihnk
18:52 < ior3k> I see
18:53 < Rando> but ive been stuck for the last few days. im not sure where to go with it next, becuase i still only have a partial picture in my head of where to go with it all
18:53 < ior3k> so how are we going to force him to tell us the whole story? :)
18:55 < ior3k> is he working on the mapping branch, too?
18:56 < Rando> i was trying to get him to flesh out the wiki page some for us
18:56 < Rando> no, i think he's working on dorb.
18:58 < ior3k> I think I understand some of it, from yesterday's pasties
18:58 < Rando> ior3k: i understand quite a bit, if you have some questions, you can ask me. maybe it'll jar something loose for me, too
19:00 < ior3k> ok, so basically he plans to have a set of properties for each repository, or a shared set and then some repository specific, is that it?
19:00 < Rando> i think so. my last question was about that exact thing, but he hasn't gotten back yet
19:00 < ior3k> ok
19:01 < ior3k> will Property be a base class? Will each repository have its own property implementation?
19:02 < Rando> yes, and i think so
19:03 < Rando> each adapter will have its own property implementation
19:03 < ior3k> will Property track changes in the model or is that left for Persistence?
19:03 < ior3k> that's nice
19:05 < ior3k> will there be non-mappable properties? For example, in the case of EV, or multi-column types
19:06 < ior3k> (which I hopeill come to replace EV)
19:06 < Rando> eventually, but thats not part of 0.9
19:07 < ior3k> so no EV for 0.9?
19:07 < Rando> i'm not sure, is it on the roadmap?
19:07 < ior3k> not seeing it there
19:08 < Rando> probably not then, unless we get this done early enough to do it
19:08 < ior3k> so 0.9 will break a lot off stuff
19:08 < Rando> oh yeah
19:08 < ior3k> hmmm
19:09 < ior3k> isn't the schedule too aggressive, then?
19:10 < ior3k> I'm thinking if stuff will break, maybe we should break it all the way so that we will have a stable base to work with, afterwards
19:11 < Rando> ior3k: yeah, thats what I'm doing
19:11 < Rando> the original plan was just to rename things, but keep them mostly the same
19:11 < ior3k> ah, great
19:11 < Rando> I'm trying to figure out what the end goal is, and do that instead, and not worrying about breaking things
19:12 < ior3k> Rando: agree
19:13 < ior3k> I'd also like to have ssmoot's blessing to merge custom types in
19:14 < ior3k> custom types + mappings will be hard to merge with each other, I think
19:21 < ior3k> oh, well, I guess I'll post my ideast to the group
19:21 < ior3k> perhaps it will foster some discussion
19:25 < Rando> ior3k: why will it be hard? It only effects the DM::Property class, right?
19:26 < ssmoot> hey guys.
19:26 < Rando> your ears burning, ssmoot? :)
19:26 < ssmoot> So I don't see why Property would need to be sub-classed. I think EV probably becomes something of a MultiProperty or something as well. But we can put that off until the end.
19:27 < ssmoot> Rando: I was hoping the pastie answered the properties/repository mapping questions. What leaves you scratching your head?
19:27 < ssmoot> ior3k: so you're on the same page: http://pastie.textmate.org/private/bmpht5kp714aaajd2mxa
19:28 < ssmoot> regarding sub-classing Property: I meant I don't see why it needs repo-specific subclasses I meant. I think it should be fairly generic. A generic descriptor for how to map a property. The Adapter should decide how to select/map that property to columns/file-fields/etc.
19:30 < ssmoot> Rando, ior3k: Make sense?
19:30 < Rando> ssmoot: yeah, i get the adapter/property stuff
19:31 < Rando> the relationships between Persistence, Container and Model are subtle, though
19:31 < ssmoot> Rando: k. So what questions isn't the pastie answering for ya? Let's hash this out and we can put it on the wiki. :)
19:31 < ssmoot> Rando: right. ok, so want me to focus on that bit then?
19:31 < Rando> sure
19:32 < ssmoot> k. Gimmie a few minutos...
19:32 < Rando> i have some ideas, too, so same for me :)
19:34 < Rando> i think earlier i was getting the concept of Container vs Model mixed up
19:34 < ior3k> ssmoot: I think I understand
19:35 < ior3k> ssmoot: but I don't like having to specify a property all over again when there's something different about it
19:36 < Rando> but when I realized a container could have several different kinds of models in it (like a RecentChanges ReST resource) it became somewhat clearer
19:37 < ior3k> ssmoot: also, what if some repositories have specific settings not shared by all of them
19:38 < ior3k> Rando: now it's me who doesn't understand
19:39 < ior3k> brb
19:44 < Rando> gonna grab a sandwich, brb
19:50 < ssmoot> ior3k: So for 0.9.0 we're not supporting repo-specific functionality.
19:51 < ssmoot> ior3k: We should be able to map to the 90% level of functionality with every repo with the generic stuff.
19:52 < ssmoot> ior3k: And ok, I could see the complaint about specifying the property again, but let's move that argument for later. Because we need the results to work the same either way. So later we can have a helper to make that a little more painless.
20:08 < dkubb> ssmoot: on line 125 exec_sql is missing an end block: http://github.com/sam/do/tree/master/do_sqlite3/lib/do_sqlite3.rb
20:09 < dkubb> end keyword I mean
20:10 < ssmoot> dkubb: doth thou have github access? I shall give thee commit rights. :)
20:10 < dkubb> sure, I'm "dkubb" on github
20:12 < ssmoot> dkubb: done.
20:12 < ior3k770> ssmoot: ok, I understand
20:12 < ssmoot> ior3k770: workin' on the wiki. All should be revealed momentarily. :)
20:12 < ior3k770> ssmoot: woohoo!
20:13 < ior3k770> ssmoot: my next question is: did you have time to look at custom types?
20:15 < ior3k770> ssmoot: I'm sking because thinking about merging that with the mapping changes is giving me shivers
20:15 < ssmoot> ior3k770: no, sorry. I'll make that a priority for today.
20:16 < ior3k770> ssmoot: well, at least you don't think it's garbage... Yet :)
20:18 < bernerdschaefer> What's the colloquy command to refresh if you're not seeing messages?
20:19 < ior3k770> ssmoot: here's the mini docs: http://pastie.caboo.se/pastes/156151
20:20 < ssmoot> bernerdschaefer: /reload style
20:20 < bernerdschaefer> Excellent. That was going to be my guess
20:21 < ior3k770> ssmoot: feel free to ask questions
20:21 < ior3k770> ssmoot: I'll be around for a while
20:22 < ssmoot> ior3k770: cool, thanks.
20:23 < bernerdschaefer> What is the use case for these custom types?
20:26 < Rando> ssmoot, ior3k770: here's how its organized in my head, currently: http://pastie.textmate.org/157770
20:27 < Rando> its a little different from what we discussed
20:28 < ior3k770> bernerdschaefer: mostly, validation reuse and custom loading and serializing
20:28 < ior3k770> bernerdschaefer: Imagine you have a type Name
20:29 < ior3k770> bernerdschaefer: which has a firstname and a lastname
20:29 < ssmoot> Rando: http://wiki.datamapper.org/doku.php?id=organizationalchanges
20:29 < Rando> ssmoot: awesome
20:30 < ior3k770> bernerdschaefer: but it is stored in the DB as "lastname, firstname"
20:30 < ssmoot> Rando: so Model in your pastie is basically a rename of DM::Base right?
20:30 < ssmoot> Rando: I'm cool with that if so.
20:30 < Rando> ssmoot: pretty much, yeah
20:31 < ssmoot> Rando: Also cool with the change to Persistable.
20:31 < Rando> ssmoot: a model is something different from container
20:32 < ssmoot> Rando: Well, a Model is a Container through mixins. yes/no?
20:32 < Rando> roughly
20:32 < Rando> ssmoot: a container has instances of models in it
20:32 < ssmoot> Rando: k. Model is also obviously a Persistable as well tho'.
20:33 < ssmoot> Rando: that's what I don't follow. I think if I give you a few minutes to read up on the wiki updates that'll be clear. Then you can explain to me what you're thinking.
20:33 < Rando> ssmoot: but once we get away from RDMSs, its entirely possible that a container might have different types of model in it, though
20:33 < Rando> ok
20:34 < bernerdschaefer> ior3k770: Right, ok. And the idea behind your pastie is to let any custom object map to any field_type in the DB, while using your own materialize/serialize
20:35 < dkubb> is there a plan to allow layering of datasources. like say Memcache in front of an RDBMS?
20:35 < dkubb> so if there's a miss at one layer, it goes to the next layer, and so on, until it runs out (and propagates an error to the caller/returns nil) or has a hit and returns the data
20:36 < ssmoot> dkubb: I'd say not datasource layering since that would be pretty heavy-weight (read: slow) to go through 2 query ops, but definitely plan to add a second-level-cache eventually, which would allow for things like MemCache support to be configured.
20:38 < ssmoot> dkubb: So Cache layering yes. Which basically means responding to #[] and #[]=, but Repository layering, not just yet.
20:38 * ssmoot break...
20:38 < dkubb> ssmoot: cache layering is mainly what I'd use it for. something like: in-memory | memcache | RDBMS
20:48 < Rando> ssmoot: ok, i read it
20:53 < Rando> ssmoot: You're using Container and model interchangably, and I don't think they are, quite exactly
20:55 < Rando> ssmoot: Container is more like a ruby array ["string", 1, MyObject.new, ...] with #get and #[] methods on it, and it has instances of Models in it. The models will usually be the same type, but not always.
20:56 < ssmoot> Rando: yeah, so basically, in the implementation example, that's what I imagined the guts of Container to be.
20:57 < ssmoot> Rando: it sounds like you're working on an entirely different idea. :) I'm not sure what this structure is trying to accomplish?
20:57 < ssmoot> this structure you're describing I mean.
20:58 < Rando> ssmoot: its required for working with ReST resources, for example, or something like couchdb
20:59 < ssmoot> Rando: but why? What is it? What does this Array-like structure actually _do_? Where does it fit into the call-stack? What methods are we calling on it and what are we expecting it to return?
21:01 < ior3k770> ssmoot: I just read the wiki. I think I understand, although I'll have to think a bit more about it
21:02 < Rando> ssmoot: I'm still not entirely clear on the relationship between Model, Persistable and Container myself :)
21:04 < ssmoot> Rando: ok. So basically I imagined Container to be a mixin for a plain Ruby object that gave you mapping related methods like #property, #container_name, #set_container_name and #properties. All the finders/saves/etc would stay in Persistable. So the mappings go into Container. Container is mixed into a class. Now that class can be mapped to a Repository.
21:04 < ssmoot> Rando: you're saying Container is not a module but a class? And that it's like an Array? That's what I don't get... ?
21:06 < ior3k770> ssmoot: I don't get persistable
21:06 < ssmoot> ior3k770: it's just a renamed DM::Persistence minus the mapping-specific methods.
21:06 < ior3k770> ssmoot: why are saves, etc, there and not in container?
21:07 < ssmoot> ior3k770: because #save, #first, #all, #destroy, etc are persistence related methods. Container is the descriptor. So the difference between Container and Persistable is the difference between Declarations and Behaviour respectively.
21:07 < Rando> ssmoot: by doing that, you're forcing Containers to be homogeneous. is that what we want?
21:09 < ssmoot> Rando: I don't understand big words. :)
21:09 < ssmoot> homogenous?
21:09 < Rando> ssmoot: We have a decision to make here. Either we allow non-homogeneous Containers, or Datamapper's support for things like XML, ReST, or even YAML repositories will be incomplete
21:09 < Rando> [Person, Person, Person], rather than [Person, Animal, Zoo]
21:11 < Rando> Container looks very similar to Enumerable, but with searching and other stuff
21:12 < ssmoot> Rando: I'm still not following what you're describing. Why would http://localhost/zoos return [Person, Animal, Zoo]? And why is that result-set a Container anyways? Are you suggesting that the result of finders is not Arrays, but some sort of specialized Collection?
21:13 < Rando> http://localhost/recently_changed_objects might return different things
21:14 < ssmoot> Rando: right, but that's not identifiable as a Resource. I think it's more of a custom action.
21:14 < Rando> ssmoot: aren't the results of finders already something other than Arrays? So that we can do things like #each over it more efficiently?
21:15 < Rando> ssmoot: yeah, thats a resource, too
21:15 < ssmoot> Rando: either way, I think we could go back and forth on wether that's RESTful or not, and we'll probably eventually support something like it, but for now I think we just need to be able to map against strict REST style uri's. At least to start.
21:15 < ssmoot> Rando: nope. finder results are just arrays.
21:17 < ssmoot> Rando: checkout the new heading here: http://wiki.datamapper.org/doku.php?id=organizationalchanges "The Difference Between Container and Persistable"
21:17 < ior3k770> ssmoot: but it seems persistable is just a bunch of convenience methods now, right?
21:18 < Rando> ssmoot: Rails' style Rest isn't strict rest. There's lots of different uri schemes that are all Restful
21:18 < ssmoot> ior3k770: right. and I hadn't invisioned that changing. They'll still just delegate to DM::Context.
21:18 < dkubb> for some reason I thought the plan was that finder results are objects that keep track of the finder arguments, but don't actually execute the SQL queries until each or other enumerable methods are called on them
21:19 < ssmoot> Rando: ok. I could buy into that. Just the same, we should be able to handle uris like that in Adapter#materialize because it'll instantiate different types for the different elements returned.
21:19 < Rando> ssmoot (and everyone else): Just tossing this out there. what do you think of something like this? http://pastie.textmate.org/157796
21:20 < ssmoot> dkubb: you're describing something like Ambition's kicker methods. Which I think would be pretty cool to do. It's not what happens now though. Shouldn't be hard to support it, but thar be bigger fish to fry ATM. Eventually we could support it by replacing the Persistable convenience methods with Kicker objects or something tho'.
21:22 < ssmoot> Rando: I'm not sure I follow. With what I've been describing you wouldn't have RecentlyChangedObjects.first without Persistable. So what are you envisioning as the responsibilities of Container vs Persistable?
21:22 < ior3k770> ssmoot: who controls checking out for dirty attributes?
21:23 < ior3k770> Rando: not following either
21:25 < ssmoot> ior3k770: good question. We're going to do away with #original_values and provide genuine property-notification instead. Not sure where that's going to live yet, maybe in Property. Low priority for now though, for now we keep #original_values in Persistable until we get to the point we replace it. Which is after all this discussion/implementation. :)
21:25 < ior3k770> ssmoot: lol
21:26 < Rando> ssmoot: in almost all cases, the container is going to be inferred from (or set in) the model. it would be kinda neat if, for example, declaring the Person model gave you the People container. Then you could write your own containers if you wanted to
21:27 < ssmoot> Rando: this is one of those times I wish we were in the same room with a white-board. :( I'm still completely confused at what your idea of a Container is, what it does, what it's purpose in life is.
21:27 < Rando> ssmoot: a container is a group of models
21:28 < Rando> and thats it. thats all it does
21:28 < ssmoot> Rando: for what purpose? [Zoo.first, Animal.first, Exhibit.first]. That's a group of model instances as well. What would I use it for, and more importantly, why does DM need to build/consume such a structure?
21:28 < ior3k770> Rando: by group, do you mean set?
21:29 < Rando> ssmoot: there is no Model#first
21:29 < ssmoot> Rando: and why am I including a Container module into my Ruby classes if it's basically an Array?
21:29 < ssmoot> Rando: is there some quick pseudo-code you could whip up for Container? Maybe that would flip the light-bulb on for me? Or is it already in your git repo soemwhere?
21:30 < Rando> ssmoot: I'm kinda making it up as i go :) its an idea i had while reading the wiki page
21:31 < Rando> ssmoot: ill pastie something, sec
21:31 < ssmoot> Rando: awesome. I'm completely lost. :)
21:36 < ior3k770> ssmoot: ok, I think I got what you mean
21:37 < ior3k770> ssmoot: I like it
21:38 < Rando> ssmoot: http://pastie.textmate.org/157804
21:38 < ior3k770> ssmoot: it's simple, that's a big thing
21:39 < ssmoot> I updated the Persistable/Container heading with an extra comment just to answer the "why?" question.
21:39 < Rando> ssmoot: A model is a standard ruby class that happens to be persistable (saveable)
21:40 < Rando> ssmoot: a container is something that can retrieve these models from an arbitrary source
21:40 < ior3k770> Rando: so a container is a special collection
21:41 < Rando> ssmoot: in almost all cases, a container will be similarly names to the homogeneous model types it returns People.all returns a collection of Person objects
21:41 < Rando> ior3k770: right
21:41 < ssmoot> Rando: so how does the All container know of the mappings in order to instantiate those models?
21:42 < Rando> ssmoot: in the similarly names ones, its easy :)
21:42 < ssmoot> Rando: right, got that. :) But All...?
21:43 < Rando> ssmoot: http://pastie.textmate.org/157807
21:44 < Rando> this is an example of a document from our restful rails app
21:44 < Rando> there's a _type attribute we use to determine what model a thing is
21:44 < Rando> XML and YAML have similar things, too
21:45 < ssmoot> Rando: k. So basically through the _type? So this is basically just the same mechanism used for STI.
21:45 < Rando> a yaml file with type: http://pastie.textmate.org/157809
21:45 < Rando> ssmoot: yeah, it would be great for STI, too :)
21:46 < ssmoot> Rando: right now property copying and everything happens through inheritance with STI, but DM always tries to instantiate by the :type column, so the Inheritance portion of STI isn't strictly necessary.
21:46 < Rando> but every data store thats not homogeneous has to provide type data
21:48 < ssmoot> Rando: makes sense. But then again, it sounds like what you're looking for isn't what I've been describing as Container, which is simply declarative. You're describing pure behaviour. More what I've been thinking of for Persistable. Except your version of things doesn't assume the type is available. It only wants the URI.
21:48 < ssmoot> So I think I understand the broad-strokes now.
21:49 < Rando> ssmoot: cool
21:49 < Rando> ssmoot: also, this is completely different from both AR, and the java ORMs we're sorta trying to emulate
21:50 < ssmoot> Here's my suggestion then: We forget about this *for now*. We can definitely revisit it later (and soon hopefully), but we push it past the goals for 1.0 because we've already got a decent amount of work to do, and introducing a new concept beyond the things we're already trying to accomplish is going to be a challenge.
21:50 < ssmoot> Rando: different: agreed. And to be honest, I kinda like that.
21:50 < Rando> ssmoot: but i think thats ok. people will either be coming to DM because there's something about AR that annoys them, and they're looking for something better. Or theyre new to it, and came here from ruby and merb.
21:52 < ssmoot> Rando: It seems we might have been pie-in-the-skying two sides of the same coin. I had an idea a week or so ago that every object would be identified not by an id or a #key, but by a URI in DM. For example: "mysql://localhost/zoos/1", or "sqlite3:///dev.db/zoos/1" or "http://localhost:4000/zoos/1".
21:53 < Rando> ssmoot: thats harder for xml or yaml files, but not a bad idea
21:54 < Rando> ssmoot: nah, in xml, its an xpath
21:54 < ssmoot> So the URI idea seemed pretty powerful to me at the time, and a natural extension of RESTyness at a much lower level than AR. One of those kinda "game changing" ideas, but I figure too aggresive an idea for 1.0.
21:54 < ssmoot> Rando: exactly.
21:54 < Rando> ok, i like your plan
21:54 < ssmoot> Rando: xml:///folder-of-xml-files/zoos.xml/*zoos
21:55 < ssmoot> Rando: or something. been awhile since I did any xpath. :) (I like it tho')
21:55 < Rando> ssmoot: or, most important xml nodes should have an id attribute that would work fine
21:55 < Rando> xml://zoos.xml[id=denver_zoo]
21:55 < Rando> yaml://zoos.yml[:denver_zoo]
21:55 < Rando> etc...
21:56 < ssmoot> Rando: but anyways, yeah, I think you and I have been thinking of two sides of the same coin. Which is cool, but I think we need to table those ideas for the immediate work, and focus on getting DM 1.0 out the door.
21:56 < Rando> each adapter would provide its own way of getting and generating ids
21:56 < ssmoot> Rando: right, exactly.
21:57 < Rando> ssmoot: ok, so where are we then? My mappings branch is mostly done, but I was getting hung up on this piece.
21:57 < ssmoot> Rando: so it might be something like: Zoo.first.uri(:legacy)
21:58 < ssmoot> Rando: so basically if you can make sure your stuff works like the wiki description (eg: that the #container_name and #properties methods take a repository_name argument and we add #field_name and #field_type to Property), then that task is basically done.
21:59 < ssmoot> And we can move onto making DM work with it, updating DM to work with the new DO, integrating ior3k770's type changes, etc.
21:59 < ssmoot> Rando: and your migrations. definitely. we need to make sure your migrations make it into DM by 1.0 for sure.
22:00 < Rando> the migrations are easy. they don't rely on anything internal to DM at all
22:00 < ssmoot> other "fun" tasks: replace Callbacks with Aquarium/AOP.
22:00 < Rando> i'll probably just use the adapters directly
22:01 < ssmoot> Rando: sweet. Maybe we should add them to a dm-more gem on second thought. I wanted to split out this AR-compatibility stuff anyways and go all Merb-like with dm-core and dm-more. No time like the present I suppose.
22:02 < Rando> ssmoot: or maybe even a step lower, and make dm_migrations reliant on dorb, but not dm
22:03 < Rando> ssmoot: I think if there's anything we think doesn't belong in dm-core, then we shouldn't bother with it at all
22:03 < Rando> we're not nearly as big as merb, and we don't really have any optional parts.
22:04 < ssmoot> Rando: I agree, but other peeps want to make contributions for things I don't think should be a part of DM, so I'd like to have a sort of convenient "official" way for people to distribute that code.
22:04 < Rando> ssmoot: ah, i see
22:04 < Rando> dm-contrib :)
22:04 < ssmoot> Rando: so there's code like is_a_tree, or AR compatibility stuff like #find, that shouldn't be part of DM-core I think.
22:04 < ssmoot> or maybe I take that back about is_a_tree.
22:05 < ssmoot> Rando: right.
22:08 < ezmobius> ssmoot: aquarium is slow, just fyi
22:09 < ssmoot> Rando: ior3k770: so we're all on the same page?
22:10 < ssmoot> ezmobius: bummer. Maybe we'll just write a quick method-wrapping DSL to do what we need then...
22:10 < ssmoot> ezmobius: or do you have any suggestions otherwise?
22:10 < ezmobius> what exactly do you need to accomplish?
22:12 < ssmoot> ezmobius: two things: I just generally want to get rid of Callbacks. Because it's kinda a lame structure for what could as easily be accomplished through method overwrites. Secondly, and potentially more importantly, I want to do what c# O/RM's I'm familiar with call Property-Notification for change-tracking instead of storing/duping #original_values for #dirty? checking.
22:13 < ssmoot> ezmobius: So the second case should lower our memory foot-print as well as increase performance a good deal.
22:14 < ssmoot> ezmobius: btw, if you've been following along at all and have any interest, I'd appreciate any criticism you could offer regarding: http://wiki.datamapper.org/doku.php?id=organizationalchanges
22:15 < Rando> ssmoot: sounds good to me. I can work on Column/Property and the SQL=>Adapters, but I don't think I can work on Container/Persistence now that I know the 'right' answer :)
22:15 < ssmoot> ReinH: ping?
22:15 < ReinH> ssmoot: pong?
22:15 < ssmoot> Rando: so difficult. :)
22:15 < ssmoot> ReinH: just wondering if you had any comments on any of this. :)
22:17 < ezmobius> looks like good changes to me
22:17 < ezmobius> i have some weird backends i want to integrate DM with so have a flixible adapters is a big win
22:17 < Rando> ssmoot: I'm gonna write up the container idea on the wiki
22:18 < Rando> ezmobius: yeah, we have a custom JSON format I want to write an adapter for
22:18 < Rando> ssmoot, ezmobius: couchdb and monetdb would also be neat to have DM adapters for...
22:19 < ssmoot> Rando: yeah, I expect we'll start piling on the adapters in point-releases post 1.0.
22:19 < ezmobius> entrepot
22:20 < ReinH> ssmoot: sorry, haven't been following
22:20 < ReinH> reading the wiki
22:20 < ssmoot> ReinH: that's cool.
22:20 < ezmobius> is an erlang/mnesia/xmpp heirarchal time based db we are making
22:20 < ezmobius> and want to have a DM backend for
22:20 < ReinH> ezmobius: oooh, that sounds interesting
22:20 < ReinH> ezmobius: what kind of problems is it designed for?
22:21 < ezmobius> it's going to be our cluster backbone
22:21 < ezmobius> full distributed and federated data store for all cluster and slice config, as well as an xmpp message bus for ruby based agents running on slices
22:22 < ReinH> ezmobius: all of those things sound very sexy ;)
22:22 < argv[]> i was just thinking about non-sql related persistance in DM the other day for yard
22:22 < ReinH> ssmoot: can I make a suggestion?
22:23 < ReinH> I like these changes a lot, actually
22:23 < ReinH> I think we should have optional includes that provide a more domain specific api
22:24 < ReinH> include RDBAPI lets you use Zoo.table_name(:legacy) etc
22:25 < ReinH> they can basically just be aliases in the most part, I would imagine
22:25 < ReinH> these can be added later, incrementally, of course
22:26 < ReinH> Also, I am a big fan of miins over inheritance for adding behavior
22:26 < ReinH> *mixins
22:26 < ReinH> so this is an all-around win for me
22:26 < ReinH> :D
22:27 < ReinH> ssmoot, ezmobius: thoughts?
22:28 < ezmobius> mixins++
22:40 < ssmoot> ReinH: sounds good to me. So yeah, DM is all mixin happy now. No need to inherit from DM::Base. Can just include DM::Perisistence.
22:40 < ReinH> w00t!
22:40 < ssmoot> ReinH: but yeah, that domain-api-specific stuff sounds like an ideal candidate for dm-more.
22:40 < ssmoot> ReinH: btw, the include persistence stuff has been that way for... a couple months now probably. ;)
22:41 < ReinH> riiight
22:41 < ReinH> sweet
23:12 < ior3k770> Hey, guys
23:12 < ior3k770> Sorry, my battery went out
23:13 < ior3k770> I just read the whole conversation
23:13 < ior3k770> ssmoot: seems fine with me
23:14 < ior3k770> ssmoot: anything you'd like me to work in for 0.9?
23:15 < ssmoot> ior3k770: Not sure ATM. A generic method-wrapping interface to replace callbacks?
23:16 < ior3k770> ssmoot: that'd be great
23:16 < ssmoot> ior3k770: maybe just base it on Merb's dispatcher?
23:17 < ior3k770> ssmoot: sure, I'll take a look
23:17 < ior3k770> I'll draft something in the wiki
23:17 < dkubb> ssmoot: was it you that was talking about aquarium for the callback stuff?
23:18 < ssmoot> ior3k770: I haven't sat down to fully grok why merb uses Continuations there. ezmobius: so merb's dispatcher is obviously more than fast enough for X number of web-requests. You think the continuations are going to hurt us much on raw method-dispatch speed tho'?
23:18 < ssmoot> dkubb: yeah, I think so. ezmobius says it's slow.
23:18 < ezmobius> continuations?
23:18 < dkubb> so many apps have that before, after and around callback systems. its funny that there's not a generic one out there
23:19 < ssmoot> dkubb: so I figured we don't need quite so robust a system as aquarium probably. more like before/after/around_filters.
23:19 < ezmobius> merb doesnt use continuations anywhere
23:19 < ssmoot> ezmobius: no? hmm... lemme see what I was mistaking then...
23:21 < ssmoot> ezmobius: http://github.com/wycats/merb-core/tree/master/lib/merb-core/controller/abstract_controller.rb in _dispatch (line 185): what's this? "caught = catch(:halt) do"
23:21 < ior3k770> I gotta go sleep, talk to you guys tomorrow
23:21 < ior3k770> Cheers
23:21 < ssmoot> ezmobius: I thought that was a continuation, but I always forget how they work 5 minutes after going through yet-another-continuations-explanation, so I could be completely wrong. :)
23:22 < ssmoot> ior3k770: cyas, g'night
23:22 < ezmobius> catch and throw are kinda like OO gotos ' :P
23:25 < ssmoot> ezmobius: ok. read up on it. I guess I always thought they were a part of continuations in Ruby, but not at all... cool.
23:26 < ssmoot> learn something new every day I suppose... now what evil things do I do in DM with this new-found knowledge... ;)
23:26 < ezmobius> yeah it sets up a catchpont so when you throw :halt inside of that bloack it will reutn to the catch :halt statement
23:26 < ezmobius> and you can throw :hatl, "foobar"
23:26 < ezmobius> to return "foobar"
23:26 < ezmobius> so you can easily change the control flow
23:27 < ssmoot> interesting... so this is how you might easily change the flow-control using an event-system like Rev?
23:28 < ssmoot> I was wondering that the other day, but didn't have time to look into how people were actually using it...
23:28 < ssmoot> (polling libs that is like Rev/EventMachine)
--- Log closed Wed Feb 27 00:00:18 2008
00:00 < dkubb> is the idea with DO to cast the data to a default ruby type based on the column type, unless another type is specified?
00:01 < RailsAddict> dkubb: no, that's just what RbMysql is doing at the moment.
00:01 < RailsAddict> the idea is to use the property :name, :type => String declarations
00:03 < dkubb> ahh, so by default alot of stuff will come out as a String unless someone specifies the property :type
00:03 < RailsAddict> DO will pass an array of types to the Reader, and the reader will cast each value based on that array.
00:04 < bernerdschaefer_> Well, property declarations always require a :type, so inside DM the types will be set by #set_types
00:05 < RailsAddict> yup
00:05 < bernerdschaefer_> Presumably, though, there could be an instance where you just want DO to load a row directly from the column types
00:07 < bernerdschaefer_> And that means DM will be doing almost no type casting -- it will all happen in C on the driver side
00:07 < bernerdschaefer_> Which is Cool(tm)
00:08 < RailsAddict> bernerdschaefer_: would it be wise to work on a shared library that we could use to handle date parsing and such?
00:08 < RailsAddict> do_fast_date_parse(char *) or the like
00:08 < bernerdschaefer_> Probably so. I thought about that
00:09 < RailsAddict> its really only those 3 methods though, date, time, datetime
00:10 < RailsAddict> and mysql just gives me an array or strings, whereas it looks like the sqlite driver gives you strings/ints/longs, etc.
00:11 < bernerdschaefer_> Yeah. The only part that feels weird just copy/pasting is the math stuff for generating the time fractions
00:12 < bernerdschaefer_> I do feel that we should coordinate on the function names, though... Maybe share a .h file with the #defines and the basic api?
00:13 < bernerdschaefer_> Or maybe not. Maybe just make sure they're all the same
00:14 < RailsAddict> Dunno man. I wish I could work on this stuff right now...
00:15 < RailsAddict> The libraries aren't that big right now, and I can't see them getting much larger method-wise.
00:15 < bernerdschaefer_> Yeah
00:16 < RailsAddict> unfortunately the only time I get to work on this stuff is early in the morning, when all sane people are snoozing.
00:16 < bernerdschaefer_> heh
00:24 < dkubb> how do you make a decimal property, and specify it precision and scale?
03:10 < afrench> anyone alive?
03:11 < bernerdschaefer_> Sort of
03:12 < afrench> you bernerd
03:12 < afrench> yo*
03:12 < bernerdschaefer_> wazza?
03:12 < afrench> watchin' the game, having a bud.....you?
03:13 < bernerdschaefer_> watchin' the game... havin' a bud. You?
03:13 < bernerdschaefer_> (PS, I love you man!)
03:13 < afrench> hold on.....HEY DOOKIE
03:14 < afrench> PICK UP THE PHONE
03:14 < dookie> Waaaaaasssssuuuuppppppp
03:14 < bernerdschaefer_> Man. The old days. When commercials that sucked sucked funnily
03:14 < afrench> totally
03:14 < bernerdschaefer_> (I know that's not a word, but I like it)
03:15 < kenphused> omg... i just saw a dallas mav cheerleader i would write bad checks for
03:15 < bernerdschaefer_> heh
03:16 < afrench> "I would bounce-checks for you".....now _that's_ a pick-up line
03:16 < kenphused> lol
03:22 < afrench> has anyone used Validatable's Group Validations (or contextual validations) with DM yet?
03:22 < bernerdschaefer_> You?
03:22 < afrench> was thinking about it pretty hard the other day
03:22 < afrench> http://adam.speaksoutofturn.com/archives/51
03:22 < afrench> and I'm thinking DM doesn't really effectively support it
03:23 < afrench> I had to overload save() so that I could pass it which group of validations to test against
03:23 < bernerdschaefer_> I saw that
03:23 < afrench> I shouldn't have to do that, right?
03:24 < bernerdschaefer_> Don't know. It does looks suspiciously hard to do, given that we include Validateable by default
03:24 < afrench> how do you mean?
03:24 < afrench> oh oh, sorry, yeah
03:27 < afrench> really seems like .save() should take a :group from validatable
03:30 < bernerdschaefer_> Yeah. Though, I suppose that would be easy enough to add into /lib on DM::Persistence
03:30 < bernerdschaefer_> But it would be nice to add and then, you know, brag about the feature
03:31 < afrench> default it to :save, probably
03:32 < bernerdschaefer_> brb, got to walk down to the PDK and get some cigarettes
03:32 < afrench> pdk?
03:32 < bernerdschaefer_> Pretty Darn Kwik? I dunno. The convenience store across from campus
03:33 < afrench> aah, gotcha
03:57 < pius> hi everyone
03:58 < pius> does anyone have a best practice approach for loading seed data? I'm suffering a bit under the destructive migrations ;)
04:07 < afrench> seed data for development?
04:08 < pius> yup
04:08 < afrench> rspec mocks and stubs aren't enough?
04:08 < pius> I'll need to do it for prod later as well
04:09 < pius> for dev, that would be enough
04:09 < pius> but not for prod
04:09 < pius> (obviously)
04:10 < afrench> there's a fixtures method in the spec-helper for datamapper that's _really_ handy
04:10 < afrench> I don't think its part of the public API, but your more than welcome to it
04:11 < pius> ah, cool
04:44 < myobie> pius: i just used the Faker gem today and a rake task to load up 20000 random records
04:45 < pius> myobie: I forgot about faker! Thanks a bunch. :)
05:29 < dkubb> ssmoot: Looks like there is a syntax error at line 125 of do_sqlite3/lib/do_sqlite3.rb: http://github.com/sam/do/commit/48f265d364c91d84456a1a57c6515bb026f3c343 (the inspect method was added without its own end tag)
10:29 < argv[]> http://yard.soen.ca/docs/datamapper-0.3.0/diagram.png
10:30 < argv[]> wee
10:55 < ior3k> Rando: ping?
14:56 < ior3k> Rando: ping?
15:56 < SuprNoodles> what's the best way to get 'acts_as_list' type functionality into datamapper? should I just write my own stuff to get it? or is there a plugin someone can recommend?
16:55 < Rando> ior3k: pong
17:31 < SuprNoodles> is there a datamapper plugin for acts_as_list?
17:33 < afrench> SuprNoodles: check out is_a_list
17:38 < SuprNoodles> thanks afrench - checking it out now
17:38 < afrench> I haven't used it, personally, but I've seen it and seen commits on it
17:44 < SuprNoodles> afrench: is it on git-hub?
17:45 < afrench> not super sure....I think it's in dm/ somewheres
17:46 < bernerdschaefer> I think there's only is_a_tree
17:47 < afrench> it's in /lib/data_mapper/is/tree.rb
17:48 < Rando> ssmoot: ping
17:50 < ssmoot> Rando: I live-eth.
17:51 < Rando> when you're setting up a model class, how do you specify which adapter it should use?
17:56 < Rando> class Person; repository = :foo_repo; end
17:56 < Rando> ?
17:59 < ssmoot> Rando: right now you don't. The model will just map to any repository with it's default attributes.
18:00 < ssmoot> Rando: let me pastie something real quick.
18:00 < Rando> ok
18:08 * ssmoot pasted http://pastie.textmate.org/private/bmpht5kp714aaajd2mxa
18:08 < ssmoot> Rando: ^^^
18:10 < ssmoot> Rando: I meant to write pseudo-code, but I think that may actually be very close to the actual implementation. ;) Except that DataMapper::Container would set the class-ivars of course, and they'd probably need to be accessed through methods so they could handle derived classes as well for inheritance.
18:10 * ssmoot is bouncing around the office this morning, but I'll keep abreast of the convo. :)
18:11 < Rando> ssmoot: np
18:13 < bernerdschaefer> Hmm.. Anyone tried installing ruby 1.9 from the svn tag?
18:14 < bernerdschaefer> Er.. hm. Nevermind
18:16 < Rando> ssmoot: whats the need for the cross-repo feature of models? Seems like quite a bit of extra work for something that would get used pretty rarely, if at all
18:16 < bernerdschaefer> Sweet. YARV, 1.9, Rubinius are all set up.. now time to run to class!
18:25 < ssmoot> Rando: because it's cool. :) And easy. And we need it at Wieck.
18:26 < ssmoot> Rando: and by 0.9.0 we hope to have a YamlAdapter to replace fixtures. So it'll get used by pretty much everyone...
18:26 < ssmoot> Everyone who uses fixtures now in their tests anyways. ;)
18:26 < Rando> ssmoot: ah, right
18:26 < Rando> not me, fixtures are a PITA
18:27 < ssmoot> Which is a good argument for mapping any repo with defaults actually vs always mapping explicitly since it would just be a pain to have to opt-in every model to your fixtures repo.
18:29 < Rando> ssmoot: i mean the cross-repo stuff; different properties based on the repo
18:38 < ior3k> ssmoot: ping?
18:48 < ior3k> Rando: ping?
18:49 < Rando> ior3k: yo
18:49 < ior3k> hey
18:49 < ior3k> I have a few ideas and a few doubts about the organizational changes
18:50 < Rando> ior3k: welcome to the club :)
18:50 < ior3k> Rando: lol
18:50 < ior3k> Rando: so what's the status on the whole thing? Does the wiki count?
18:50 < Rando> sorta
18:51 < ior3k> is the mapping branch kind of experimental, or is it supposed to be the definitive implementation?
18:51 < Rando> the only official spec is in sam's head. I've gleaned quite a bit from him in irc over the last few weeks, and some of that is in the wiki
18:52 < Rando> its about 1/3 of where we want to go with it, i tihnk
18:52 < ior3k> I see
18:53 < Rando> but ive been stuck for the last few days. im not sure where to go with it next, becuase i still only have a partial picture in my head of where to go with it all
18:53 < ior3k> so how are we going to force him to tell us the whole story? :)
18:55 < ior3k> is he working on the mapping branch, too?
18:56 < Rando> i was trying to get him to flesh out the wiki page some for us
18:56 < Rando> no, i think he's working on dorb.
18:58 < ior3k> I think I understand some of it, from yesterday's pasties
18:58 < Rando> ior3k: i understand quite a bit, if you have some questions, you can ask me. maybe it'll jar something loose for me, too
19:00 < ior3k> ok, so basically he plans to have a set of properties for each repository, or a shared set and then some repository specific, is that it?
19:00 < Rando> i think so. my last question was about that exact thing, but he hasn't gotten back yet
19:00 < ior3k> ok
19:01 < ior3k> will Property be a base class? Will each repository have its own property implementation?
19:02 < Rando> yes, and i think so
19:03 < Rando> each adapter will have its own property implementation
19:03 < ior3k> will Property track changes in the model or is that left for Persistence?
19:03 < ior3k> that's nice
19:05 < ior3k> will there be non-mappable properties? For example, in the case of EV, or multi-column types
19:06 < ior3k> (which I hopeill come to replace EV)
19:06 < Rando> eventually, but thats not part of 0.9
19:07 < ior3k> so no EV for 0.9?
19:07 < Rando> i'm not sure, is it on the roadmap?
19:07 < ior3k> not seeing it there
19:08 < Rando> probably not then, unless we get this done early enough to do it
19:08 < ior3k> so 0.9 will break a lot off stuff
19:08 < Rando> oh yeah
19:08 < ior3k> hmmm
19:09 < ior3k> isn't the schedule too aggressive, then?
19:10 < ior3k> I'm thinking if stuff will break, maybe we should break it all the way so that we will have a stable base to work with, afterwards
19:11 < Rando> ior3k: yeah, thats what I'm doing
19:11 < Rando> the original plan was just to rename things, but keep them mostly the same
19:11 < ior3k> ah, great
19:11 < Rando> I'm trying to figure out what the end goal is, and do that instead, and not worrying about breaking things
19:12 < ior3k> Rando: agree
19:13 < ior3k> I'd also like to have ssmoot's blessing to merge custom types in
19:14 < ior3k> custom types + mappings will be hard to merge with each other, I think
19:21 < ior3k> oh, well, I guess I'll post my ideast to the group
19:21 < ior3k> perhaps it will foster some discussion
19:25 < Rando> ior3k: why will it be hard? It only effects the DM::Property class, right?
19:26 < ssmoot> hey guys.
19:26 < Rando> your ears burning, ssmoot? :)
19:26 < ssmoot> So I don't see why Property would need to be sub-classed. I think EV probably becomes something of a MultiProperty or something as well. But we can put that off until the end.
19:27 < ssmoot> Rando: I was hoping the pastie answered the properties/repository mapping questions. What leaves you scratching your head?
19:27 < ssmoot> ior3k: so you're on the same page: http://pastie.textmate.org/private/bmpht5kp714aaajd2mxa
19:28 < ssmoot> regarding sub-classing Property: I meant I don't see why it needs repo-specific subclasses I meant. I think it should be fairly generic. A generic descriptor for how to map a property. The Adapter should decide how to select/map that property to columns/file-fields/etc.
19:30 < ssmoot> Rando, ior3k: Make sense?
19:30 < Rando> ssmoot: yeah, i get the adapter/property stuff
19:31 < Rando> the relationships between Persistence, Container and Model are subtle, though
19:31 < ssmoot> Rando: k. So what questions isn't the pastie answering for ya? Let's hash this out and we can put it on the wiki. :)
19:31 < ssmoot> Rando: right. ok, so want me to focus on that bit then?
19:31 < Rando> sure
19:32 < ssmoot> k. Gimmie a few minutos...
19:32 < Rando> i have some ideas, too, so same for me :)
19:34 < Rando> i think earlier i was getting the concept of Container vs Model mixed up
19:34 < ior3k> ssmoot: I think I understand
19:35 < ior3k> ssmoot: but I don't like having to specify a property all over again when there's something different about it
19:36 < Rando> but when I realized a container could have several different kinds of models in it (like a RecentChanges ReST resource) it became somewhat clearer
19:37 < ior3k> ssmoot: also, what if some repositories have specific settings not shared by all of them
19:38 < ior3k> Rando: now it's me who doesn't understand
19:39 < ior3k> brb
19:44 < Rando> gonna grab a sandwich, brb
19:50 < ssmoot> ior3k: So for 0.9.0 we're not supporting repo-specific functionality.
19:51 < ssmoot> ior3k: We should be able to map to the 90% level of functionality with every repo with the generic stuff.
19:52 < ssmoot> ior3k: And ok, I could see the complaint about specifying the property again, but let's move that argument for later. Because we need the results to work the same either way. So later we can have a helper to make that a little more painless.
20:08 < dkubb> ssmoot: on line 125 exec_sql is missing an end block: http://github.com/sam/do/tree/master/do_sqlite3/lib/do_sqlite3.rb
20:09 < dkubb> end keyword I mean
20:10 < ssmoot> dkubb: doth thou have github access? I shall give thee commit rights. :)
20:10 < dkubb> sure, I'm "dkubb" on github
20:12 < ssmoot> dkubb: done.
20:12 < ior3k770> ssmoot: ok, I understand
20:12 < ssmoot> ior3k770: workin' on the wiki. All should be revealed momentarily. :)
20:12 < ior3k770> ssmoot: woohoo!
20:13 < ior3k770> ssmoot: my next question is: did you have time to look at custom types?
20:15 < ior3k770> ssmoot: I'm sking because thinking about merging that with the mapping changes is giving me shivers
20:15 < ssmoot> ior3k770: no, sorry. I'll make that a priority for today.
20:16 < ior3k770> ssmoot: well, at least you don't think it's garbage... Yet :)
20:18 < bernerdschaefer> What's the colloquy command to refresh if you're not seeing messages?
20:19 < ior3k770> ssmoot: here's the mini docs: http://pastie.caboo.se/pastes/156151
20:20 < ssmoot> bernerdschaefer: /reload style
20:20 < bernerdschaefer> Excellent. That was going to be my guess
20:21 < ior3k770> ssmoot: feel free to ask questions
20:21 < ior3k770> ssmoot: I'll be around for a while
20:22 < ssmoot> ior3k770: cool, thanks.
20:23 < bernerdschaefer> What is the use case for these custom types?
20:26 < Rando> ssmoot, ior3k770: here's how its organized in my head, currently: http://pastie.textmate.org/157770
20:27 < Rando> its a little different from what we discussed
20:28 < ior3k770> bernerdschaefer: mostly, validation reuse and custom loading and serializing
20:28 < ior3k770> bernerdschaefer: Imagine you have a type Name
20:29 < ior3k770> bernerdschaefer: which has a firstname and a lastname
20:29 < ssmoot> Rando: http://wiki.datamapper.org/doku.php?id=organizationalchanges
20:29 < Rando> ssmoot: awesome
20:30 < ior3k770> bernerdschaefer: but it is stored in the DB as "lastname, firstname"
20:30 < ssmoot> Rando: so Model in your pastie is basically a rename of DM::Base right?
20:30 < ssmoot> Rando: I'm cool with that if so.
20:30 < Rando> ssmoot: pretty much, yeah
20:31 < ssmoot> Rando: Also cool with the change to Persistable.
20:31 < Rando> ssmoot: a model is something different from container
20:32 < ssmoot> Rando: Well, a Model is a Container through mixins. yes/no?
20:32 < Rando> roughly
20:32 < Rando> ssmoot: a container has instances of models in it
20:32 < ssmoot> Rando: k. Model is also obviously a Persistable as well tho'.
20:33 < ssmoot> Rando: that's what I don't follow. I think if I give you a few minutes to read up on the wiki updates that'll be clear. Then you can explain to me what you're thinking.
20:33 < Rando> ssmoot: but once we get away from RDMSs, its entirely possible that a container might have different types of model in it, though
20:33 < Rando> ok
20:34 < bernerdschaefer> ior3k770: Right, ok. And the idea behind your pastie is to let any custom object map to any field_type in the DB, while using your own materialize/serialize
20:35 < dkubb> is there a plan to allow layering of datasources. like say Memcache in front of an RDBMS?
20:35 < dkubb> so if there's a miss at one layer, it goes to the next layer, and so on, until it runs out (and propagates an error to the caller/returns nil) or has a hit and returns the data
20:36 < ssmoot> dkubb: I'd say not datasource layering since that would be pretty heavy-weight (read: slow) to go through 2 query ops, but definitely plan to add a second-level-cache eventually, which would allow for things like MemCache support to be configured.
20:38 < ssmoot> dkubb: So Cache layering yes. Which basically means responding to #[] and #[]=, but Repository layering, not just yet.
20:38 * ssmoot break...
20:38 < dkubb> ssmoot: cache layering is mainly what I'd use it for. something like: in-memory | memcache | RDBMS
20:48 < Rando> ssmoot: ok, i read it
20:53 < Rando> ssmoot: You're using Container and model interchangably, and I don't think they are, quite exactly
20:55 < Rando> ssmoot: Container is more like a ruby array ["string", 1, MyObject.new, ...] with #get and #[] methods on it, and it has instances of Models in it. The models will usually be the same type, but not always.
20:56 < ssmoot> Rando: yeah, so basically, in the implementation example, that's what I imagined the guts of Container to be.
20:57 < ssmoot> Rando: it sounds like you're working on an entirely different idea. :) I'm not sure what this structure is trying to accomplish?
20:57 < ssmoot> this structure you're describing I mean.
20:58 < Rando> ssmoot: its required for working with ReST resources, for example, or something like couchdb
20:59 < ssmoot> Rando: but why? What is it? What does this Array-like structure actually _do_? Where does it fit into the call-stack? What methods are we calling on it and what are we expecting it to return?
21:01 < ior3k770> ssmoot: I just read the wiki. I think I understand, although I'll have to think a bit more about it
21:02 < Rando> ssmoot: I'm still not entirely clear on the relationship between Model, Persistable and Container myself :)
21:04 < ssmoot> Rando: ok. So basically I imagined Container to be a mixin for a plain Ruby object that gave you mapping related methods like #property, #container_name, #set_container_name and #properties. All the finders/saves/etc would stay in Persistable. So the mappings go into Container. Container is mixed into a class. Now that class can be mapped to a Repository.
21:04 < ssmoot> Rando: you're saying Container is not a module but a class? And that it's like an Array? That's what I don't get... ?
21:06 < ior3k770> ssmoot: I don't get persistable
21:06 < ssmoot> ior3k770: it's just a renamed DM::Persistence minus the mapping-specific methods.
21:06 < ior3k770> ssmoot: why are saves, etc, there and not in container?
21:07 < ssmoot> ior3k770: because #save, #first, #all, #destroy, etc are persistence related methods. Container is the descriptor. So the difference between Container and Persistable is the difference between Declarations and Behaviour respectively.
21:07 < Rando> ssmoot: by doing that, you're forcing Containers to be homogeneous. is that what we want?
21:09 < ssmoot> Rando: I don't understand big words. :)
21:09 < ssmoot> homogenous?
21:09 < Rando> ssmoot: We have a decision to make here. Either we allow non-homogeneous Containers, or Datamapper's support for things like XML, ReST, or even YAML repositories will be incomplete
21:09 < Rando> [Person, Person, Person], rather than [Person, Animal, Zoo]
21:11 < Rando> Container looks very similar to Enumerable, but with searching and other stuff
21:12 < ssmoot> Rando: I'm still not following what you're describing. Why would http://localhost/zoos return [Person, Animal, Zoo]? And why is that result-set a Container anyways? Are you suggesting that the result of finders is not Arrays, but some sort of specialized Collection?
21:13 < Rando> http://localhost/recently_changed_objects might return different things
21:14 < ssmoot> Rando: right, but that's not identifiable as a Resource. I think it's more of a custom action.
21:14 < Rando> ssmoot: aren't the results of finders already something other than Arrays? So that we can do things like #each over it more efficiently?
21:15 < Rando> ssmoot: yeah, thats a resource, too
21:15 < ssmoot> Rando: either way, I think we could go back and forth on wether that's RESTful or not, and we'll probably eventually support something like it, but for now I think we just need to be able to map against strict REST style uri's. At least to start.
21:15 < ssmoot> Rando: nope. finder results are just arrays.
21:17 < ssmoot> Rando: checkout the new heading here: http://wiki.datamapper.org/doku.php?id=organizationalchanges "The Difference Between Container and Persistable"
21:17 < ior3k770> ssmoot: but it seems persistable is just a bunch of convenience methods now, right?
21:18 < Rando> ssmoot: Rails' style Rest isn't strict rest. There's lots of different uri schemes that are all Restful
21:18 < ssmoot> ior3k770: right. and I hadn't invisioned that changing. They'll still just delegate to DM::Context.
21:18 < dkubb> for some reason I thought the plan was that finder results are objects that keep track of the finder arguments, but don't actually execute the SQL queries until each or other enumerable methods are called on them
21:19 < ssmoot> Rando: ok. I could buy into that. Just the same, we should be able to handle uris like that in Adapter#materialize because it'll instantiate different types for the different elements returned.
21:19 < Rando> ssmoot (and everyone else): Just tossing this out there. what do you think of something like this? http://pastie.textmate.org/157796
21:20 < ssmoot> dkubb: you're describing something like Ambition's kicker methods. Which I think would be pretty cool to do. It's not what happens now though. Shouldn't be hard to support it, but thar be bigger fish to fry ATM. Eventually we could support it by replacing the Persistable convenience methods with Kicker objects or something tho'.
21:22 < ssmoot> Rando: I'm not sure I follow. With what I've been describing you wouldn't have RecentlyChangedObjects.first without Persistable. So what are you envisioning as the responsibilities of Container vs Persistable?
21:22 < ior3k770> ssmoot: who controls checking out for dirty attributes?
21:23 < ior3k770> Rando: not following either
21:25 < ssmoot> ior3k770: good question. We're going to do away with #original_values and provide genuine property-notification instead. Not sure where that's going to live yet, maybe in Property. Low priority for now though, for now we keep #original_values in Persistable until we get to the point we replace it. Which is after all this discussion/implementation. :)
21:25 < ior3k770> ssmoot: lol
21:26 < Rando> ssmoot: in almost all cases, the container is going to be inferred from (or set in) the model. it would be kinda neat if, for example, declaring the Person model gave you the People container. Then you could write your own containers if you wanted to
21:27 < ssmoot> Rando: this is one of those times I wish we were in the same room with a white-board. :( I'm still completely confused at what your idea of a Container is, what it does, what it's purpose in life is.
21:27 < Rando> ssmoot: a container is a group of models
21:28 < Rando> and thats it. thats all it does
21:28 < ssmoot> Rando: for what purpose? [Zoo.first, Animal.first, Exhibit.first]. That's a group of model instances as well. What would I use it for, and more importantly, why does DM need to build/consume such a structure?
21:28 < ior3k770> Rando: by group, do you mean set?
21:29 < Rando> ssmoot: there is no Model#first
21:29 < ssmoot> Rando: and why am I including a Container module into my Ruby classes if it's basically an Array?
21:29 < ssmoot> Rando: is there some quick pseudo-code you could whip up for Container? Maybe that would flip the light-bulb on for me? Or is it already in your git repo soemwhere?
21:30 < Rando> ssmoot: I'm kinda making it up as i go :) its an idea i had while reading the wiki page
21:31 < Rando> ssmoot: ill pastie something, sec
21:31 < ssmoot> Rando: awesome. I'm completely lost. :)
21:36 < ior3k770> ssmoot: ok, I think I got what you mean
21:37 < ior3k770> ssmoot: I like it
21:38 < Rando> ssmoot: http://pastie.textmate.org/157804
21:38 < ior3k770> ssmoot: it's simple, that's a big thing
21:39 < ssmoot> I updated the Persistable/Container heading with an extra comment just to answer the "why?" question.
21:39 < Rando> ssmoot: A model is a standard ruby class that happens to be persistable (saveable)
21:40 < Rando> ssmoot: a container is something that can retrieve these models from an arbitrary source
21:40 < ior3k770> Rando: so a container is a special collection
21:41 < Rando> ssmoot: in almost all cases, a container will be similarly names to the homogeneous model types it returns People.all returns a collection of Person objects
21:41 < Rando> ior3k770: right
21:41 < ssmoot> Rando: so how does the All container know of the mappings in order to instantiate those models?
21:42 < Rando> ssmoot: in the similarly names ones, its easy :)
21:42 < ssmoot> Rando: right, got that. :) But All...?
21:43 < Rando> ssmoot: http://pastie.textmate.org/157807
21:44 < Rando> this is an example of a document from our restful rails app
21:44 < Rando> there's a _type attribute we use to determine what model a thing is
21:44 < Rando> XML and YAML have similar things, too
21:45 < ssmoot> Rando: k. So basically through the _type? So this is basically just the same mechanism used for STI.
21:45 < Rando> a yaml file with type: http://pastie.textmate.org/157809
21:45 < Rando> ssmoot: yeah, it would be great for STI, too :)
21:46 < ssmoot> Rando: right now property copying and everything happens through inheritance with STI, but DM always tries to instantiate by the :type column, so the Inheritance portion of STI isn't strictly necessary.
21:46 < Rando> but every data store thats not homogeneous has to provide type data
21:48 < ssmoot> Rando: makes sense. But then again, it sounds like what you're looking for isn't what I've been describing as Container, which is simply declarative. You're describing pure behaviour. More what I've been thinking of for Persistable. Except your version of things doesn't assume the type is available. It only wants the URI.
21:48 < ssmoot> So I think I understand the broad-strokes now.
21:49 < Rando> ssmoot: cool
21:49 < Rando> ssmoot: also, this is completely different from both AR, and the java ORMs we're sorta trying to emulate
21:50 < ssmoot> Here's my suggestion then: We forget about this *for now*. We can definitely revisit it later (and soon hopefully), but we push it past the goals for 1.0 because we've already got a decent amount of work to do, and introducing a new concept beyond the things we're already trying to accomplish is going to be a challenge.
21:50 < ssmoot> Rando: different: agreed. And to be honest, I kinda like that.
21:50 < Rando> ssmoot: but i think thats ok. people will either be coming to DM because there's something about AR that annoys them, and they're looking for something better. Or theyre new to it, and came here from ruby and merb.
21:52 < ssmoot> Rando: It seems we might have been pie-in-the-skying two sides of the same coin. I had an idea a week or so ago that every object would be identified not by an id or a #key, but by a URI in DM. For example: "mysql://localhost/zoos/1", or "sqlite3:///dev.db/zoos/1" or "http://localhost:4000/zoos/1".
21:53 < Rando> ssmoot: thats harder for xml or yaml files, but not a bad idea
21:54 < Rando> ssmoot: nah, in xml, its an xpath
21:54 < ssmoot> So the URI idea seemed pretty powerful to me at the time, and a natural extension of RESTyness at a much lower level than AR. One of those kinda "game changing" ideas, but I figure too aggresive an idea for 1.0.
21:54 < ssmoot> Rando: exactly.
21:54 < Rando> ok, i like your plan
21:54 < ssmoot> Rando: xml:///folder-of-xml-files/zoos.xml/*zoos
21:55 < ssmoot> Rando: or something. been awhile since I did any xpath. :) (I like it tho')
21:55 < Rando> ssmoot: or, most important xml nodes should have an id attribute that would work fine
21:55 < Rando> xml://zoos.xml[id=denver_zoo]
21:55 < Rando> yaml://zoos.yml[:denver_zoo]
21:55 < Rando> etc...
21:56 < ssmoot> Rando: but anyways, yeah, I think you and I have been thinking of two sides of the same coin. Which is cool, but I think we need to table those ideas for the immediate work, and focus on getting DM 1.0 out the door.
21:56 < Rando> each adapter would provide its own way of getting and generating ids
21:56 < ssmoot> Rando: right, exactly.
21:57 < Rando> ssmoot: ok, so where are we then? My mappings branch is mostly done, but I was getting hung up on this piece.
21:57 < ssmoot> Rando: so it might be something like: Zoo.first.uri(:legacy)
21:58 < ssmoot> Rando: so basically if you can make sure your stuff works like the wiki description (eg: that the #container_name and #properties methods take a repository_name argument and we add #field_name and #field_type to Property), then that task is basically done.
21:59 < ssmoot> And we can move onto making DM work with it, updating DM to work with the new DO, integrating ior3k770's type changes, etc.
21:59 < ssmoot> Rando: and your migrations. definitely. we need to make sure your migrations make it into DM by 1.0 for sure.
22:00 < Rando> the migrations are easy. they don't rely on anything internal to DM at all
22:00 < ssmoot> other "fun" tasks: replace Callbacks with Aquarium/AOP.
22:00 < Rando> i'll probably just use the adapters directly
22:01 < ssmoot> Rando: sweet. Maybe we should add them to a dm-more gem on second thought. I wanted to split out this AR-compatibility stuff anyways and go all Merb-like with dm-core and dm-more. No time like the present I suppose.
22:02 < Rando> ssmoot: or maybe even a step lower, and make dm_migrations reliant on dorb, but not dm
22:03 < Rando> ssmoot: I think if there's anything we think doesn't belong in dm-core, then we shouldn't bother with it at all
22:03 < Rando> we're not nearly as big as merb, and we don't really have any optional parts.
22:04 < ssmoot> Rando: I agree, but other peeps want to make contributions for things I don't think should be a part of DM, so I'd like to have a sort of convenient "official" way for people to distribute that code.
22:04 < Rando> ssmoot: ah, i see
22:04 < Rando> dm-contrib :)
22:04 < ssmoot> Rando: so there's code like is_a_tree, or AR compatibility stuff like #find, that shouldn't be part of DM-core I think.
22:04 < ssmoot> or maybe I take that back about is_a_tree.
22:05 < ssmoot> Rando: right.
22:08 < ezmobius> ssmoot: aquarium is slow, just fyi
22:09 < ssmoot> Rando: ior3k770: so we're all on the same page?
22:10 < ssmoot> ezmobius: bummer. Maybe we'll just write a quick method-wrapping DSL to do what we need then...
22:10 < ssmoot> ezmobius: or do you have any suggestions otherwise?
22:10 < ezmobius> what exactly do you need to accomplish?
22:12 < ssmoot> ezmobius: two things: I just generally want to get rid of Callbacks. Because it's kinda a lame structure for what could as easily be accomplished through method overwrites. Secondly, and potentially more importantly, I want to do what c# O/RM's I'm familiar with call Property-Notification for change-tracking instead of storing/duping #original_values for #dirty? checking.
22:13 < ssmoot> ezmobius: So the second case should lower our memory foot-print as well as increase performance a good deal.
22:14 < ssmoot> ezmobius: btw, if you've been following along at all and have any interest, I'd appreciate any criticism you could offer regarding: http://wiki.datamapper.org/doku.php?id=organizationalchanges
22:15 < Rando> ssmoot: sounds good to me. I can work on Column/Property and the SQL=>Adapters, but I don't think I can work on Container/Persistence now that I know the 'right' answer :)
22:15 < ssmoot> ReinH: ping?
22:15 < ReinH> ssmoot: pong?
22:15 < ssmoot> Rando: so difficult. :)
22:15 < ssmoot> ReinH: just wondering if you had any comments on any of this. :)
22:17 < ezmobius> looks like good changes to me
22:17 < ezmobius> i have some weird backends i want to integrate DM with so have a flixible adapters is a big win
22:17 < Rando> ssmoot: I'm gonna write up the container idea on the wiki
22:18 < Rando> ezmobius: yeah, we have a custom JSON format I want to write an adapter for
22:18 < Rando> ssmoot, ezmobius: couchdb and monetdb would also be neat to have DM adapters for...
22:19 < ssmoot> Rando: yeah, I expect we'll start piling on the adapters in point-releases post 1.0.
22:19 < ezmobius> entrepot
22:20 < ReinH> ssmoot: sorry, haven't been following
22:20 < ReinH> reading the wiki
22:20 < ssmoot> ReinH: that's cool.
22:20 < ezmobius> is an erlang/mnesia/xmpp heirarchal time based db we are making
22:20 < ezmobius> and want to have a DM backend for
22:20 < ReinH> ezmobius: oooh, that sounds interesting
22:20 < ReinH> ezmobius: what kind of problems is it designed for?
22:21 < ezmobius> it's going to be our cluster backbone
22:21 < ezmobius> full distributed and federated data store for all cluster and slice config, as well as an xmpp message bus for ruby based agents running on slices
22:22 < ReinH> ezmobius: all of those things sound very sexy ;)
22:22 < argv[]> i was just thinking about non-sql related persistance in DM the other day for yard
22:22 < ReinH> ssmoot: can I make a suggestion?
22:23 < ReinH> I like these changes a lot, actually
22:23 < ReinH> I think we should have optional includes that provide a more domain specific api
22:24 < ReinH> include RDBAPI lets you use Zoo.table_name(:legacy) etc
22:25 < ReinH> they can basically just be aliases in the most part, I would imagine
22:25 < ReinH> these can be added later, incrementally, of course
22:26 < ReinH> Also, I am a big fan of miins over inheritance for adding behavior
22:26 < ReinH> *mixins
22:26 < ReinH> so this is an all-around win for me
22:26 < ReinH> :D
22:27 < ReinH> ssmoot, ezmobius: thoughts?
22:28 < ezmobius> mixins++
22:40 < ssmoot> ReinH: sounds good to me. So yeah, DM is all mixin happy now. No need to inherit from DM::Base. Can just include DM::Perisistence.
22:40 < ReinH> w00t!
22:40 < ssmoot> ReinH: but yeah, that domain-api-specific stuff sounds like an ideal candidate for dm-more.
22:40 < ssmoot> ReinH: btw, the include persistence stuff has been that way for... a couple months now probably. ;)
22:41 < ReinH> riiight
22:41 < ReinH> sweet
23:12 < ior3k770> Hey, guys
23:12 < ior3k770> Sorry, my battery went out
23:13 < ior3k770> I just read the whole conversation
23:13 < ior3k770> ssmoot: seems fine with me
23:14 < ior3k770> ssmoot: anything you'd like me to work in for 0.9?
23:15 < ssmoot> ior3k770: Not sure ATM. A generic method-wrapping interface to replace callbacks?
23:16 < ior3k770> ssmoot: that'd be great
23:16 < ssmoot> ior3k770: maybe just base it on Merb's dispatcher?
23:17 < ior3k770> ssmoot: sure, I'll take a look
23:17 < ior3k770> I'll draft something in the wiki
23:17 < dkubb> ssmoot: was it you that was talking about aquarium for the callback stuff?
23:18 < ssmoot> ior3k770: I haven't sat down to fully grok why merb uses Continuations there. ezmobius: so merb's dispatcher is obviously more than fast enough for X number of web-requests. You think the continuations are going to hurt us much on raw method-dispatch speed tho'?
23:18 < ssmoot> dkubb: yeah, I think so. ezmobius says it's slow.
23:18 < ezmobius> continuations?
23:18 < dkubb> so many apps have that before, after and around callback systems. its funny that there's not a generic one out there
23:19 < ssmoot> dkubb: so I figured we don't need quite so robust a system as aquarium probably. more like before/after/around_filters.
23:19 < ezmobius> merb doesnt use continuations anywhere
23:19 < ssmoot> ezmobius: no? hmm... lemme see what I was mistaking then...
23:21 < ssmoot> ezmobius: http://github.com/wycats/merb-core/tree/master/lib/merb-core/controller/abstract_controller.rb in _dispatch (line 185): what's this? "caught = catch(:halt) do"
23:21 < ior3k770> I gotta go sleep, talk to you guys tomorrow
23:21 < ior3k770> Cheers
23:21 < ssmoot> ezmobius: I thought that was a continuation, but I always forget how they work 5 minutes after going through yet-another-continuations-explanation, so I could be completely wrong. :)
23:22 < ssmoot> ior3k770: cyas, g'night
23:22 < ezmobius> catch and throw are kinda like OO gotos ' :P
23:25 < ssmoot> ezmobius: ok. read up on it. I guess I always thought they were a part of continuations in Ruby, but not at all... cool.
23:26 < ssmoot> learn something new every day I suppose... now what evil things do I do in DM with this new-found knowledge... ;)
23:26 < ezmobius> yeah it sets up a catchpont so when you throw :halt inside of that bloack it will reutn to the catch :halt statement
23:26 < ezmobius> and you can throw :hatl, "foobar"
23:26 < ezmobius> to return "foobar"
23:26 < ezmobius> so you can easily change the control flow
23:27 < ssmoot> interesting... so this is how you might easily change the flow-control using an event-system like Rev?
23:28 < ssmoot> I was wondering that the other day, but didn't have time to look into how people were actually using it...
23:28 < ssmoot> (polling libs that is like Rev/EventMachine)
--- Log closed Wed Feb 27 00:00:18 2008
Reply all
Reply to author
Forward
0 new messages