00:31
<postmodern>
has anyone used Devise with DataMapper?
00:31
<postmodern>
it appears to support DataMapper as an ORM
00:31
<postmodern>
i've heard people are using it with rails3 currently
01:45
<postmodern>
darn, it looks like devise expects AR named validation methods
01:45
<postmodern>
that could easily be fixed though, via a lookup-table or dummy methods
02:30
ashley_moran joined
05:37
<g0bl1n>
hi, can I have a property in my model based on the sum of severall form values ?
05:37
<g0bl1n>
can those values be computed in the model ?
05:39
<g0bl1n>
simple example: property :birthday I'd like to have it composed by :day, :month, :year in the form, then computed in the model
05:39
<g0bl1n>
how would I do that in the model ?
05:41
<g0bl1n>
Since I'd like my form to "see" :day, :month and :year properties
05:41
<solnic>
g0bl1n: you could set it in a before :valid? hook
05:42
<namelessjon>
g0bl1n: Or set day, month, year as accessors, and use a default to set it from them.
05:42
<g0bl1n>
namelessjon, like in a method for the :birthdate property ?
05:43
<namelessjon>
Well, what solnic suggested is probably better, especially for changing birthdays
05:44
<g0bl1n>
but I'd have to set the accessorts too, in Solnic case, right ?
05:44
<g0bl1n>
* accessors
05:44
<namelessjon>
g0bl1n: Yeah, I think so.
05:45
<namelessjon>
I mean, the other option is just to handle this in the controller. It's not like you'd be setting the birthday in lots of places.
05:46
<postmodern>
related to g0bl1n's question, im wondering if or when might dm-core support rendering SQL Views or stored procedures?
05:46
<g0bl1n>
yes, that'd be an option, to deal with it in the controller, but for code cleaningness, wouldn't the model be the right place ?
05:46
<postmodern>
seems like it would be a feasible abstract someday
05:46
<namelessjon>
postmodern: If you make a model of the view, it works fine, afaik.
05:46
<postmodern>
namelessjon, interesting, nice
05:46
<g0bl1n>
postmodern, yes, I almost went there, but not for my simple case. I'll have to deal with it in a week or two :-)
05:47
<solnic>
g0bl1n: yup, just use attr_accessor :bd_year, :bd_month, :bd_day and then before :valid? { self.birthday = Date.new(bd_year, bd_month, bd_day) }
05:47
<postmodern>
seems like in the future you could define a stored procedure (if the adapter supported them) by passing in a lambda of a query
05:48
<g0bl1n>
ty solnic I'll go that way ;)
05:48
<postmodern>
or define a view that way
05:48
<solnic>
g0bl1n: doing it in a controller would be against "Skinny Controller, Fat Model" rule :)
05:48
<solnic>
g0bl1n: you could also handle it in the view via JS if you want
05:49
<g0bl1n>
solnic, yes agree, but in the case I'm having I'll be composing other values
05:50
<g0bl1n>
postmodern, like creating a stored procedure, send it to the DBMS and there, use it whenever wanted ? cool
05:51
<namelessjon>
postmodern: That would never be in dm-core. :) But it could be in the various sql adapters.
05:52
<g0bl1n>
namelessjon, indeed
05:57
<solnic>
postmodern: probably such things will be introduced with DM 2.0
05:57
<postmodern>
namelessjon, well im thinking like some extra adapter method, like bind or something
05:58
<postmodern>
solnic, totally, espically with the new veritas work for generic relational algebra that dkubb is working on
05:59
<solnic>
postmodern: exactly...a lot of things will be decoupled so handling datastore-specific functionality should be easier then it is now
06:24
greeneggandham joined
10:38
<snusnu>
anyone here using dm without dm-validations regularly?
10:38
<snusnu>
(just curious)
10:53
<careo>
so, I'm a bit confused about original_attributes in 0.10.2. how are you supposed to use them?
10:53
<careo>
they're a hash with DataMapper::Property instances as keys
10:56
<namelessjon>
careo: you can lookup properties by name, get the actual property, then use the hash.
10:57
<namelessjon>
careo: I asked dkubb about this a while back. Apparently, every time they were used internally, they needed the property anyway, so he just make it a property => value hash.
10:58
<careo>
namelessjon: cool. so question 2... any idea how to do that?
10:59
<snusnu>
careo: Person.properties[:name] ?
11:01
<snusnu>
guys, can i get your opinions on the usefulness of "opting out" of dm-validations?
11:02
<careo>
sweet. that works perfectly
11:02
<careo>
snusnu: maybe if you could use dm-constraints w/o it?
11:03
<careo>
to have dm do no validation of its own, and just let the db yell at you
11:03
<snusnu>
careo: yeah, i guess as soon as one leaves the webapp realm, more usecases for not having it enabled creep up
11:04
<snusnu>
careo: i'm just fighting with a gem (dm-paperclip) that does "feature detection" and checks for DataMapper::Validate constant .. however, this just seems so brittle, and load order dependent
11:04
<careo>
snusnu: yeah. I don't really care if DM checks uniqueness with a select before doing an insert. I don't trust that as far as i can throw it
11:04
<snusnu>
careo: even more so with our friend bundler ...
11:05
<namelessjon>
snusnu: I have a small app which doesn't use validations. It uses constraints + not null, and cheerfully blows up when they're violated. (rescuing some cases)
11:05
<careo>
snusnu: I guess if it REALLY cares about it, it should do it much later in the process
11:05
<careo>
not at load time
11:05
<snusnu>
careo: yeah you're right .. require when the method is called
11:06
<careo>
it seems like there's a parallel dependency management hell that's begging for a solution....
11:07
<dkubb>
hey everyone, just got back from mwrc
11:07
<snusnu>
hey dan, hope you had a good time?
11:07
<careo>
dkubb: cool. i wish I could have gone. :(
11:07
<dkubb>
snusnu: yeah, it was really good. met lots of people
11:07
<namelessjon>
Hey dkubb, welcome back. And well done on winning rbp :) What did you win it for?
11:08
<dkubb>
tons of people using DM which was awesome to see
11:08
<dkubb>
namelessjon: oh, it was just a name draw
11:08
<dkubb>
I met with lots of people using DM with Rails, Rack, Sinatra and even met up with the maglev guys
11:09
<dkubb>
they demo'd their system for me and I think it'll be a 1-line change to add basic maglev support
11:09
<careo>
dkubb: no shit?
11:09
<dkubb>
basically we'll inherit from the in-memory adapter, and change records_for
11:09
<careo>
re: maglev :)
11:09
<dkubb>
oh yeah, it was pretty neat what they have
11:10
<careo>
yeah. I've met the guys there. gemstone is here in town actually. they host the smalltalk meetups
11:10
<snusnu>
that sounds cool
11:10
<dkubb>
the main blocker actually is just getting their system to pass specs.. I believe they support about 90% of rubyspecs, and are just starting on getting Rails to pass
11:10
<dkubb>
careo: oh, you're based in portland?
11:11
<careo>
dkubb: hillsboro to be pedantic, but yeah
11:13
<careo>
heh. I like how supporting Rails is seen as the holy grail of "yeah, we're a complete Ruby"
11:13
<careo>
while supporting Sinatra is the "see! we're getting there"
11:13
<dkubb>
I think it's because Rails does all sorts of crazy stuff
11:14
<dkubb>
or did at least
11:14
<careo>
yeah. for good or for awesome
11:14
<dkubb>
I think the internals are cleaner now, but I can imagine supporting Rails 2.x is hard
11:15
<dkubb>
snusnu: yeah I'm fine with that, although should we also remove the explicit "require 'dm-core'" from elsewhere in each package, like in spec_helper.rb
11:16
<snusnu>
dkubb: good point, i will do that too
11:16
<dkubb>
snusnu: no point in saying something twice, and it'll force us to keep the requires in the lib files
11:16
<dkubb>
snusnu: because if we forget in a year or two (which could happen), we want it to explode so we are reminded to keep it in
11:16
<dkubb>
*forget and remove it
11:16
<careo>
snusnu: maybe have a master dm loader that looks at what gems are activated and then does the requires in the righty order
11:16
<dkubb>
careo: hmm, lemme check it out
11:17
<snusnu>
dkubb: yeah, it's a good safety net, i will work throught it today evening
11:17
<dkubb>
careo: I don't have a quick solution, but I do have one..
11:17
<careo>
dkubb: I'm sure you don't, as it won't be an easy fix. I just wanted to bring the bug up again before I hack around it and make things work
11:17
<dkubb>
careo: actually conceptually it's simple.. lemme explain and tell me if you think it'll work
11:18
<snusnu>
careo: i'm not sure i understand .. it probably can't ever figure out the right order to require?
11:18
<dkubb>
careo: ok, so right now the adapter returns an Array of Hashes (I call them tuples). it maps the values onto the ivars inside the objects and then throws away the tuples
11:18
<careo>
snusnu: well, you know dm-X must be required before dm-Y, ya?
11:19
<dkubb>
careo: what I was thinking was that instead of Model#load mapping the values immediately, it just save the tuple internally
11:19
<dkubb>
careo: when someone uses an accessor, we dup the value and copy it into the ivar, and return that
11:19
<dkubb>
careo: when someone uses a mutator, we set the ivar directly
11:20
<dkubb>
careo: at save time we compare the value in the ivar against the value in the tuple, and if there's a change then we save it
11:20
<dkubb>
careo: I would probably do a "deep copy" to make sure that if there are differences in the object we can tell
11:21
<dkubb>
by deferring the deep copy we avoid any speed penalty that we'd get if we did a deep copy when the object is being loaded
11:21
<careo>
dkubb: for serialized types only, no? and where "deep" means something like Mashal.load(Marshal.dump(x))
11:22
<dkubb>
careo: yeah, I think we'd probably need to have a way to specify the algo to use to copy the value.. using Marshal like that would only be necessary for Hash, Array, etc
11:22
<dkubb>
careo: for String, Integer, Boolean, and other simple types it would be overkill
11:22
<careo>
dkubb: what about just keeping the original unserialized version?
11:22
<dkubb>
it'd still work, but it'd be alot more work than is necessary
11:23
<careo>
then deserialize it into the ivar
11:23
<dkubb>
careo: that information is inside the adapter, but not necessarily known to DM
11:23
<dkubb>
careo: we kind of want the adapter and DM to not know much about each other.. some adapters don't even have a serialized form for the object since they store it natively
11:24
<dkubb>
so like in an RDBMS, Hash would be Marshalled, but in MongoDB it'd be stored natively, so the serialized copy wouldn't be available in the second case.. however, I think the approach I have above should work everywhere
11:25
<dkubb>
and since stuff is deferred, loading an object should actually be even faster than now
11:25
<dkubb>
right now if you have say 10 properties, DM copies the value in each hash to each of the 10 ivars for each object. if you're loading 1000 objects, that's 10,000 copies. with this deferred approach we'd only be copying the tuple to a single ivar
11:26
<dkubb>
well, once for each object, so 1000 times
11:26
<dkubb>
not a huge gain, but we do want object loading to be as fast and efficient as possible
11:30
<careo>
dkubb: do you have a sense of how involved that would end up being?
11:31
<dkubb>
careo: I don't think too difficult. the first part involved modifying Model#load to no longer "eager load" the properties, as well as modifying Property#get to use the tuple if the ivar is not defined
11:32
<dkubb>
careo: that could probably be done by someone in a couple of hours. there are plenty of specs covering that behavior, so it'd just be a code change
11:32
<careo>
dkubb: cool. I'll see if I can take a look at it. now that I'm almost done working around it :)
11:33
<dkubb>
careo: the second part would be modifying Resource and Property so that to determine if an object is dirty, original_values isn't used, but rather the tuple and ivar are compared
11:34
<dkubb>
careo: when solnic's branch for the property refactor is merged in, we can make it so each type of Property has a method that figures out how to deep copy the value
11:34
<dkubb>
careo: for the most part there'll be one single simple approach, and then something more involved using Marshal
11:34
<dkubb>
in both cases the code will be simple
11:35
<dkubb>
actually String would need dup, but all the Numeric and Boolean objects don't need anything, since they are immutable and the only way to change them is to re-assign a new value to the ivart
11:49
<snusnu>
unless defined?(DataMapper::Validate).nil?
11:51
<snusnu>
i wonder if this was trying to obfuscate the meaning as much as possible :P
11:59
<careo>
snusnu: heh
11:59
<careo>
wouldn't that be the same as if defined?(...)
12:00
<snusnu>
i really think so, yes :)
12:00
<careo>
don't listen to me. I'm knee deep in code I was too proud of when I wrote it. in other words... omg wtf does it do
12:01
<irjudson>
that sounds normal
12:01
<snusnu>
haha i know what you mean … :P
12:04
<careo>
dryer than a fire nation prison for waterbenders...
12:54
<careo>
did the meaning of save! vs save change from 0.9 to 0.10?
13:03
<dkubb>
careo: no, it shouldn't have. save! means to bypass all hooks
13:03
<careo>
dkubb: oooooh
13:04
<careo>
did it in .9?
13:04
<dkubb>
careo: yeah
13:04
<dkubb>
careo: alot of people think it raises an exception
13:04
<careo>
hehe. I guess it didn't
13:04
<careo>
yeah. that's why I used it originally. I was young, and still recovering from my AR days
13:05
<careo>
I had a random spec failure and I was like, "I'll just throw a save right here?" and it worked. but it should be being saved underneath... but it's a save!
13:05
<dkubb>
I have a fix in edge DM that'll allow you to specify that when #save and #save! fails it throw an exception rather than return false
13:06
<careo>
cool. yeah, that's the behavior I was intending. I guess it ended up running the hooks anyway
13:08
<careo>
kcould there have been some change to how dm-observers work?
13:11
<dkubb>
careo: I'm not aware of any changes to dm-observers. if you're seeing some differences it could be a regression
13:11
<careo>
dkubb: I think it's a pro-gression ...
13:12
<careo>
since I was calling save! and observers were firing
13:12
<careo>
is that expected?
13:12
<careo>
or maybe my other hook was too... man. I dunno. I need to take a flame thrower to my hook and observer logic
13:12
<careo>
either way!
13:13
<dkubb>
careo: no, that shouldn't happen.. I would expect observers to be implemented using a hook. anything with a "!" should have no other side effects besides performing the action
13:13
<careo>
so either way, it's now behaving as it should, and it only worked before by accident
13:13
<dkubb>
careo: ahh ok, cool
13:14
<dkubb>
careo: I would generally question any code that uses save!, update!, etc.. it's not often you'd want to work without a safety net
13:14
<dkubb>
careo: I mean it does happen, but it should be fairly rare
13:15
<careo>
yeah. I was just trying to figure out a totally surprising set of failures after upgrading. that always concerns the crap outta me :)
13:16
<careo>
hehe true. I was thinking quite the opposite, where it was adding an extra safety net of exception-throwing goodness
13:17
<dkubb>
careo: are you going from 0.9 to 0.10?
13:17
<careo>
dkubb: yeah
13:18
<careo>
and merb 1.0.10 the 1.1 rc
13:18
<dkubb>
careo: cool. how is your spec coverage on your app?
13:18
<careo>
I mean, it's kind of an organic mass that grew as I worked, but so far it's caught every one of those "oooh shit, I broke THAT?"
13:18
<dkubb>
careo: and aside from some deprecation warnings, how has the upgrade been?
13:19
<careo>
this is the 3rd time I've tried, but this time I finally figured out the work-around for the dirty serialized bug
13:20
<careo>
s/3rd/4th. forgot one quick try earlier
13:20
<dkubb>
careo: how's it looking this time?
13:20
<careo>
only 2 failures left, and 3 pending specs I don't think I actually wanted in the first place :0
13:21
<careo>
one failure is going to be an easy fix, and the other... man.
13:21
<careo>
I wrote a simple optimistic-locking plugin that i need to update
13:21
<dkubb>
careo: did you look at some of the other ones out there?
13:22
<careo>
not recently. I did when I wrote this one, although for the life of me I can't recall why I went with my own
13:22
<careo>
I think it was because my lock column is something I manage manually
13:23
<careo>
(well, manually as in, it's part of my hairy hook and observer magic)
13:25
<careo>
that's as I have it in 0.9 (with the exception of the self.new? on line 19 of course)
13:27
<felipec>
is it possible to alias a property?
13:32
<lukegalea>
hey everyone
13:32
<lukegalea>
I'm noticing a lot of duplicated queries on our site.
13:32
<lukegalea>
Does DM have something like AR query cache?
13:32
<careo>
dkubb: does that seem sane if I port it to use the right dirty attribute stuff?
13:32
<lukegalea>
(ie. are these duplicate queries the result of a bug or a missing feature)??
13:34
<careo>
lukegalea: I don't recall seeing a query cache. I haven't really looked though
13:39
<dkubb>
lukegalea: in DM there is an IdentityMap you can use. wrap some of the code in a DataMapper.repository block to see
13:39
<dkubb>
lukegalea: it only works on #get calls tho
13:39
<lukegalea>
cool. Thanks. I'll check it out.
13:40
<dkubb>
lukegalea: I think there may be a few projects out there where people do this. in theory it should be relatively simple to make a query cache
13:40
<lukegalea>
I guess the hard part is invalidating the cache whenever there is a create, etc.
13:41
<dkubb>
lukegalea: exactly
13:41
<careo>
observers ftw?
13:41
<lukegalea>
dkubb: Thanks for the hints ;)
13:42
<dkubb>
lukegalea: although if the cache tracks the resources that are in it, Query#filter_records could be used to match which resources are in it, and if the cache needs to be cleared
13:42
<dkubb>
er that didn't come out right
13:42
<dkubb>
ok, so when you read, you check the cache for similar queries. if you find one, return the resources from the cache. if not, then you execute the query and cache the resources
13:42
<dkubb>
that part is easy
13:43
<dkubb>
the hard part is that when you create, update or delete, you can use the query from each set of cached resources to see if the object you are modifying is or should be in the set, and invalidate it
13:44
<dkubb>
Query#matches?(resource) can tell you if something belongs to a set
13:44
<lukegalea>
thanks. I'll give it a try and report back!
14:09
<namelessjon>
careo: I was just looking at that earlier
14:10
<careo>
I'm sure I can do it w/o overriding to_json, since I'm literally just overriding it to be: self.formatted_resource.to_json
14:14
<namelessjon>
careo: basically that bug appeared from changing dm-serialization to serialize in 'one go' rather than building up the json incrementally 'by ourselves'
14:14
<careo>
namelessjon: yeah
14:14
<careo>
it's probably interacting strangely w/ merb
14:15
<careo>
it works fine for a collection if I don't call to_json in my own to_json, but that has other issues w/ non-collections obviously :)
14:15
<namelessjon>
careo: Well, it might be jst dm at fault. I don't fully understand how {}.to_jsn works.
14:15
<namelessjon>
*to_json
14:16
<careo>
something like this might work: super(:only => [], :method => :formatted_resource)
14:17
<careo>
well, except it doesn't
14:21
<namelessjon>
careo: Always a problem when reality gets in the way :(
14:21
<careo>
that pesky reality
14:21
<careo>
never any good
14:33
<namelessjon>
I might just have to revert the patch, even though the new implementation is faster.
14:35
<careo>
is there some way to fall back in the case of a collection?
14:35
<namelessjon>
'fall back'?
14:35
<careo>
to the old way
14:36
<careo>
if dm can tell it only has a single resource to worry about
14:36
greeneggandham joined
14:37
<namelessjon>
Maybe. I need to get back into that code. It's been way too long :/
14:37
<careo>
hehe yeah. I know the feeling
15:11
<careo>
namelessjon: heh. If I just call #to_a on the collection before displaying it, it looks like it works
15:16
<namelessjon>
careo: Well, glad that works for you, at least
15:17
<careo>
namelessjon: yeah. so maybe the only tweak needed is to how it handles collections. the to_json for individual resources looks like it's fine
15:41
<snusnu>
careo, namelessjon: #to_json is not enough .. AS/rails now has #as_json too … from the rails changelog: JSON: +Object#to_json+ calls +as_json+ to coerce itself into something natively encodable like +Hash+, +Integer+, or +String+. Override +as_json+ instead of +to_json+ so you're JSON library agnostic.
15:41
<snusnu>
i understand that maybe i just threw that out here completely out of context :P
15:41
<careo>
snusnu: cool. although I am using neither :P
15:42
<snusnu>
careo: i hit the over quoting thing too in a toy app, i didn't care too much back then .. but i ended up writing my own as_json iirc
15:47
<snusnu>
i just never got to_json to output what i want .. overwriting #to_json (possibly adding params) seemed weird, #as_json seems like a good fit here
15:58
<namelessjon>
snusnu: That is ... more or less what to_json does, actually. then just called to_json it
16:02
<snusnu>
namelessjon: i'm not sure i follow, what is more or less what to_json does?
16:05
<namelessjon>
snusnu: #as_json. The to_json method I made basically collects everything into hashes /arrays of hashes. then calls to_json on it.
16:06
<snusnu>
namelessjon: ah ok, well, but it doesn't allow to override #as_json, because it's not a defined method, right?
16:06
<namelessjon>
snusnu: Yeah. To be honest, doing it #as_json might actually be an easier way to do things anyway.
16:06
<snusnu>
namelessjon: and that overriding part seems beneficial to me, for some situations
16:08
<snusnu>
namelessjon: it's clearly separated, #as_json allows you to specify what a resource will look like, *as json* .. and #to_json will then go ahead and spit that out
16:09
<* namelessjon>
nods
16:14
<snusnu>
namelessjon: in the long term, i wonder if/how an integration with AMo serializing could/should be done .. i've not looked at any code so far, i just noted there is such a thing as AMo serialization handling
16:15
<snusnu>
namelessjon: maybe that goes too far tho
16:15
<namelessjon>
snusnu: I'm not sure. As I said, atm #as_json and
16:15
<dkubb>
snusnu: if AMo works on regular ruby objects, without anything special, then I think it'd be ok to use that.. even replacing some of the logic from dm-serializer to use it
16:16
<namelessjon>
#to_json are ~the same method, controlled by a parameter
16:16
<dkubb>
snusnu: there are some parts of AMo that might not work for us in the future just due to some changing internals (implementing more of the DataMapper pattern, rather than ActiveRecord centric)
16:16
<dkubb>
but I don't think serialization is one of them
16:17
<dkubb>
for quick and dirty I think it's ok to have the object know how to serialize itself to json or xml, but for anything that needs to vary I'd probably use a Presenter object
16:18
<dkubb>
which is basically a view that knows how to serialize a type of object
16:18
<snusnu>
dkubb: yeah, i will eventually find the time to look at the whole AMo hopefully .. so far i only visited the "interface" part .. so not too familiar with it now
16:19
<snusnu>
dkubb: yeah, for more complex scenarios a presenter might make sense .. but i think that would match with a to_json/as_json api .. as_json returning the presenter or so
16:20
<dkubb>
snusnu: what would be ideal is if the API was that to_json returned an object that when #to_s was called on it would return a String in valid JSON format
16:20
<dkubb>
snusnu: same with to_xml, and to_yaml
16:22
<dkubb>
snusnu: what's the reason for to_json and as_json though? one returns the object in serialized form, and one that returns the object in a form that can be nested and then serialized as part of a larger object graph?
16:24
<dkubb>
to combat that problem I wonder if it'd work to just have class JSONString < String; def to_json; self end; end .. and then nesting stuff returned by to_json would work
16:24
<dkubb>
so the idea is that to_json would always return a JSONString object, allowing nesting to work fine
16:26
<snusnu>
dkubb: hmm .. lemme think about that while i eat dinner :)
16:27
<dkubb>
snusnu: ok. it's quite possible that I don't understand something subtle. then again if there is no problem with my approach, having a simple API where everything calls to_json is preferable to to separate methods like as_json and to_json
16:33
hipertracker joined
16:42
<snusnu>
dkubb: yeah i think as long as nesting works fine that's good .. i will need to read more about the json backend agnosticism that was mentioned in the rails changelog entry
16:49
greeneggandham joined
17:02
<careo>
snusnu: ah nice. I've been planning on swapping out the json library for yajl-ruby
17:07
<irjudson1>
dkubb: so just for the sake of frightening everyone, what's the worst place you can think of to store science data that an actual scientist might use?
17:07
<irjudson1>
dkubb: i have an answer, but I want to see what you'd say :-)?
17:10
<careo>
dkubb: w00t. everything passes. even my optimistic locking
17:18
<namelessjon>
irjudson1: I can answer this one! random binary files? With almost no metadata >_>
17:19
<namelessjon>
Not that I would ever do that <_<
17:19
<namelessjon>
Ever.
17:21
beawesomeinstead joined
17:36
<dkubb>
careo: awesome, good to hear it's working
17:38
<dkubb>
irjudson: worst place to store scientific data? hmm, there's probably so many places. maybe something like a web page or something that a normal scientist might not be able to scrape or access?
17:41
<careo>
irjudson: in a pdf
17:41
<careo>
preferably one that's either just images, or otherwise organized in a completely impossible to copy/paste way
17:41
<dkubb>
careo: ahh good one
17:42
<dkubb>
flash would also be bad
17:42
<dkubb>
but PDF is probably way more common
17:43
hipertracker_ joined
17:46
<irjudson>
dkubb: answer: I am not writing dm-powerpoint-adapter :-)
17:46
<irjudson>
specifically, tables in powerpoint
17:46
<dkubb>
that's worse than PDF
17:46
<irjudson>
go figure
17:46
<namelessjon>
irjudson: haha. :/
17:47
<irjudson>
feeding animals, bbs
17:47
<hassox>
hallo lads
17:47
<hassox>
quick q for anyone with the know-how...
17:47
<hassox>
is there anythnig equiv for DM as AR's find_each ?
17:48
<namelessjon>
hassox: What does it do?
17:49
<hassox>
Foo.all.each{ |foo| puts foo }
17:49
<hassox>
but it will do the finding and yielding in batches of 1000
17:51
<dkubb>
hassox: no, but any of the pagination gems can do that
17:51
<hassox>
ok i'll look into getting something together :D
18:04
<dkubb>
when you see the code object.dependencies .. does it seem like it'd return dependencies *for* object or *on* object
18:04
<dkubb>
just making the API for UoW, and trying to figure out the best names for some of the methods
18:13
<namelessjon>
dkubb: For, I think.
18:15
<dkubb>
namelessjon: cool. although I think I'm going to stick with terms like parent/child since I'm dealing with a DAG inside the UoW and need to make sure stuff happens on the parents before the children
18:16
<namelessjon>
dkubb: I much prefer parent/child, yeah
18:21
<hassox>
snusnu: you about mate?
18:37
<siplux>
is there a way to manually trigger evaluation so you could build up a query chain manually without it executing in the process?
18:39
<namelessjon>
siplux: A query fires in only a few defined cases. Essentially, when you iterate.
18:41
<siplux>
namelessjon: say you have Foo that has n Bar, if you do Foo.get(1).bars that query will trigger right? if you want to eventually build it to Foo.get(1).bars.get(2), it wouldn't work
18:42
<namelessjon>
siplux: get() will always trigger. That is it's role in the API.
18:42
<namelessjon>
siplux: You can reformulate the query as Foo.all(:id => 1).bars
18:44
<siplux>
namelessjon: but that will still return all bars? I'm mostly interested in the last part of the chain. the foo.bars vs foo.bars.get(1)
18:44
<siplux>
namelessjon: preventing .bars from returning all bars until I have a chance to call get on it
18:45
<siplux>
namelessjon: I can work around it with #send and friends, but wondering if there is any way to make it wait for execution
18:45
<namelessjon>
siplux: Oh, right, you meant the first bar belonging to foo?
18:47
<dkubb>
I actually *wish* it were possible to make Foo.get(1) return an object that is lazy
18:47
<dkubb>
but because some people do stuff like "if Foo.get(1)", you have to know if the object is available or not.. if it's nil, then that code returns false
18:48
<dkubb>
now if ruby had a #to_boolean method or something, I *could* return an object that is lazily evaluated, and loads in this situation, while in other situations allows a query to be built up
18:48
<siplux>
namelessjon: yes - basically the situation is that I need to account for parent objects existing or not, and if they do, work down the chain so that I'm either calling Bar.get(1) or foos.bars.get(1)
18:48
<siplux>
dkubb: darn - that would be helpful
18:49
<dkubb>
but because there isn't one, you'd use Foo.all(:id => 1).bars(:id => 1)
18:49
<dkubb>
then you'd get a query that represents all Bar objects with an id of 1, who belong to at least one Foo object with an id of 1.. assuming that id is a PK, then when you iterate over this it should return a single row (or nil if there's no matching resources)
18:50
<dkubb>
you can also return the object instead of a Collection by doing: Foo.all(:id => 1).bars(:id => 1).first
18:50
<dkubb>
siplux: yeah it would be awesome to have a way to evaluate an object in boolean context, but unfortunately there are no hooks for this
18:52
<StyleWarz>
morning dkubb
18:52
<siplux>
I actually want to instantiate the parents (so I'm going to do Foo.get(1) regardless), the main issue is the very last link in the chain - the parent.bars.get(1) vs Bar.get(1)
18:52
<dkubb>
StyleWarz: good afternoon
18:52
<siplux>
but i guess using #send is probably the only way to dothat
18:52
<StyleWarz>
.oO(it's almost 2 am here ;)
18:56
<careo>
what do people use for encrypting columns in the db?
18:56
<dkubb>
careo: what kind of data is it?
18:57
<careo>
dkubb: creds.
18:57
<dkubb>
careo: credit cards?
18:57
<careo>
account credentials
18:57
<dkubb>
if it were credit cards, I'd say: don't :P
18:57
<dkubb>
not unless you know what you're doing and prepared to go through the process of getting verified
18:57
<careo>
I'm upgrading to 1.9 now. we were using attr_encrypted which worked fine, not at all in 1.9
18:58
<dkubb>
so account credentials, like a password?
18:58
<careo>
creds for ec2, rackspace, etc
18:58
<careo>
so not something we can just hash and compare
18:59
<dkubb>
I haven't done any recent research on that within the last year so I don't want to give any advice that is probably outdated by now
18:59
<dkubb>
if it were a password, I would recommend Bcrypt.. but since hash and compare isn't possible I dunno
19:02
<careo>
dkubb: I mean more if there's a dm plugin
19:02
<dkubb>
careo: I haven't seen one myself
19:02
<careo>
that works w/ 1.9 :)
20:48
<postmodern>
any compliants about adding a Symbol type to DataMapper::Types
21:19
<postmodern>
snusnu, what version of activesupport is dm-core and friends going to depend on?
21:29
<snusnu>
postmodern: it'll work with 3.0.0 (beta1 for now) .. it won't *depend* on it any time soon tho, and will drop the hard extlib dependency .. since optional deps aren't possible with rubygems yet, that leaves us with no real dependency for either for some time i guess
21:30
<postmodern>
im creating active_support branches for all of my code
21:31
<snusnu>
cool, i've done so with most of mine too already
21:33
<postmodern>
yeah, it's been mostly grepping for to_const_, snake_case, extlib
21:34
<snusnu>
postmodern: and i got sidetracked today again, although this time at least with fixing other dm related stuff for AS (or rails3)
21:34
<snusnu>
postmodern: tomorrow i really wanna tackle merging AS stuff into master
21:35
<postmodern>
i saw the thread about DANA
21:35
<postmodern>
that sounds like fun stuff, after the AS merge
21:35
<snusnu>
yeah, that's gonna come after that, exactly :)
21:36
<snusnu>
i wanna keep that for last, because all the other "smaller" plugins are simpler to upgrade :P
21:37
<snusnu>
i mean, i'm not aware of any real problems with dana now, but i remember lots of troubles back then, until it reached the state it's in now … and i definitely wanna see it rock solid in my upcoming rails3 apps
21:38
<snusnu>
maybe some JS love as well
21:38
<snusnu>
if there isn't anything available for that already, haven't looked yet
21:47
<hassox>
snusnu: hey man
21:48
<snusnu>
hey hassox
21:49
<hassox>
quick q for you
21:49
<hassox>
what's the benefit of using the dm-nested-attributes plugin?
21:49
<hassox>
dm-core seems to handle nested attributes as it is
21:49
<snusnu>
hassox: it'll allow nested model assignment / multi model forms with dm .. just like with AR
21:50
<snusnu>
hassox: yeah, in the create case, but not for updating and deleting iirc
21:51
<hassox>
so I just need to include it
21:51
<snusnu>
require it, then call accepts_nested_attributes_for in your models
21:52
<hassox>
thanx dude :D
21:52
<snusnu>
hassox: i've not yet tried how it works with rails' form helpers tho
21:53
<hassox>
I'm using simple_form
21:53
<snusnu>
hassox: that's on my list tho .. probably some time next week, unless you beat me to it :P
21:53
<snusnu>
hassox: yeah well i'm not at all familiar with rails plugin world (anymore/yet)
21:53
<hassox>
quick q on it
21:53
<hassox>
why is it required if dm-core handles the create ones but not the update
21:54
<snusnu>
how do you mean required?
21:54
<hassox>
sorry conversing and typing ;)
21:54
<hassox>
I mean why do I need to load a plugin
21:54
<hassox>
shouldn't it be handled by dm-core if it's going to handle the create case?
21:55
<snusnu>
well, it's really a lot about form param passing conventions and such .. probably nothing for core
21:55
<snusnu>
i mean, i remember saying the same to dkubb at some time :)
21:56
<snusnu>
i do think that it's probably mostly used in webapps tho .. or better, in apps where lots of user input comes at some time, and you want to handle that with one call
21:57
<snusnu>
which might also be a "reason" to not have it in core necessarily
21:58
<snusnu>
i have to admit that the conventions to do an update when an ID is passed seems really sensible .. not so sure about the :_delete key tho .. maybe that could be left configurable
21:59
<snusnu>
another thing is, that in it's current state at least, it won't handle CPKs . .which is probably fine for webapps .. but not for the broader usages
22:09
maximeguilbot joined
22:17
<snusnu>
namelessjon: in case you're either still awake or happen to read the backlog, i think dm-more/dm-is-example would be a good fit for dm-gen .. it just makes no sense at all to have it as a proper gem in dm-more
22:26
<maximeguilbot>
hey all, I'm getting a undefined method `metaclass' error when I try to read an one to many relationship. i'm using edge code in the activesupport branch inside rails 3. any ideas where I should investigate?
22:27
<snusnu>
maximeguilbot: hmm weird, are running with Bundler.require ?
22:28
<snusnu>
maximeguilbot: although wait, that shouldn't be a problem, dm-core should properly require AS itself
22:28
<maximeguilbot>
snusnu: I'm using the gem bundler, looks like it broke as I did a bundle install
22:28
<snusnu>
maximeguilbot: metaclass() is defined in AS .. and i know dm-core uses it in quite some places
22:29
<maximeguilbot>
snusnu: in rails's console, I should then be able to use the metaclass method on any class, right?
22:29
<snusnu>
maximeguilbot: hmm, i sometimes see bundler not properly updating git deps that reside in branches .. i never was able to really reproduce it tho
22:29
<snusnu>
maximeguilbot: yes
22:29
<snusnu>
maximeguilbot: lemme check that as well
22:30
<snusnu>
maximeguilbot: interesting, i get methodmissing too
22:31
<maximeguilbot>
snusnu: weird, maybe I can trash my .bundle directory and re-run bundle install.. ?
22:32
<snusnu>
maximeguilbot: no, looks like a missing require in my fork
22:32
<snusnu>
maximeguilbot: at least i haven't found one that looks like it would pull that method in
22:32
<snusnu>
maximeguilbot: i will check now and if so push an updated version and then go to bed :P
22:33
<maximeguilbot>
snusnu: sorry to hold you from bed dude
22:33
<snusnu>
maximeguilbot: no worries :)
22:35
<snusnu>
maximeguilbot: holy crap, it's gone
22:35
<snusnu>
maximeguilbot: textmate find in project doesn't find it anymore
22:35
<snusnu>
maximeguilbot: in rails that is
22:36
<maximeguilbot>
snusnu: you can't find the require that would define metaclass?
22:36
<snusnu>
maximeguilbot: seems to be singleton_class now
22:36
<maximeguilbot>
snusnu: I've read smomething like this around while googling "undefined method metaclass"
22:36
<snusnu>
maximeguilbot: found it in the changelog
22:37
<maximeguilbot>
snusnu: ok, so it's actually a rails update that broke dm
22:37
<snusnu>
maximeguilbot: yup
22:39
<maximeguilbot>
snusnu: alias metaclass singleton_class ?
22:40
<snusnu>
maximeguilbot: for you as a workaround, yeah, for dm-core i'd say no .. we should go with the flow, it was renamed to prefer *ruby*'s choice
22:41
<snusnu>
maximeguilbot: hah!
22:41
<snusnu>
maximeguilbot: myabc already committed that fix!
22:41
<maximeguilbot>
snusnu: right
22:42
<maximeguilbot>
snusnu: lol
22:42
<snusnu>
maximeguilbot: so you probably should really wipe your ~/.bundle and retry?
22:43
<maximeguilbot>
snusnu: going to try this
22:43
<snusnu>
maximeguilbot: i was like, wtf, now textmate can't find metaclass in dm-core either :P
22:44
<maximeguilbot>
snusnu: my dm-core copy from .bundle isn't really up-to-date looks like
22:45
<snusnu>
maximeguilbot: i think i remember bundler having problems when the remote branch gets deleted and created again
22:45
<snusnu>
maximeguilbot: i did that back in the time when i thought i can keep it all as a single commit
22:45
<snusnu>
maximeguilbot: maybe your copy is from back then
22:45
<maximeguilbot>
snusnu: going to take a little while to fetch all those git repos again, maybe you should sleep
22:46
<snusnu>
maximeguilbot: i noticed bundler not updating stuff properly then i went with just adding commits, eventually squashing them a bit before pushing upstream
22:46
<maximeguilbot>
snusnu: I understand, thanks for your help!!
22:50
<hobbsc>
anyone using datamapper with ramaze? probably a question for the ramaze channel, but i'm looking for examples
22:52
<snusnu>
maximeguilbot: heh, actually, the commit by myabcs is incomplete … it misses a require 'active_support/core_ext/object/singleton_class'
22:52
<snusnu>
maximeguilbot: in dm-core/support/active_support.rb
22:52
<maximeguilbot>
snusnu: ok, I see, going to hack around it if necessary
22:53
<maximeguilbot>
snusnu: still cloning here..
22:53
<snusnu>
maximeguilbot: maybe some other AS dep is pulling it in tho .. in which case i'd still add it to dm-core for completeness/documentation/styling sakes .. but it shouldn't bite you
22:54
<maximeguilbot>
snusnu: I'm going to try it as it is and see if it blows :)
23:02
<snusnu>
maximeguilbot: fwiw, i pushed the explicit require to my fork .. off to bed now, good luck!
23:02
<maximeguilbot>
snusnu: thanks again for your help, good night!
23:28
<dkubb|away>
hobbsc: I know people use it, but I don't personally (although I will probably give ramaze a try soon)
23:29
<dkubb>
hassox: I think that Resource#update could be made to work with a nested Hash. actually I wouldn't be surprised if it did *just work* right now
23:29
<dkubb>
hassox: some of those conventions in Rails like _delete probably won't be supported
23:30
<hassox>
sounds good to me
23:30
<hassox>
I just found it very clean when creating nested models the other day to use the built in dm-core nested stuff
23:30
<hassox>
I hadn't got to updating yet ;)
23:32
<dkubb>
hassox: Resource#update simply routes the params to the corresponding mutator methods, and then calls Resource#save, so it should update/overwrite everything, even associations
23:32
<dkubb>
hassox: if you try it out and think there's some weird behavior, please let me know
23:33
<hassox>
that sounds awesome
23:34
<dkubb>
hassox: in general though, you should be able to do this: obj = Model.create(nested_hash); Model.first(nested_hash).should eql(obj); obj.update(nested_hash).should eql(obj)
23:34
<hassox>
that is so awesome :D
23:35
<dkubb>
hassox: nested params for queries are still kind of beta, but I'm working towards them working perfectly before 1.0
23:36
<dkubb>
hassox: yeah, it's like the flexibility of the NoSQL ORMs, but with the stability of an RDBMS
23:36
<dkubb>
or one of ~40 other backends
23:37
beawesomeinstead joined
23:37
<hassox>
are there that many now o.O
23:37
<hassox>
bloody hell
23:38
<dkubb>
hassox: yeah, something like that. I know of some companies that have closed source versions too
23:38
<dkubb>
hassox: altogether I'd estimate there are somewhere between 50 and 75 backends
23:38
<hassox>
that's so awesome
23:39
<dkubb>
I mean, granted not all of them are able to perform the same as the RDBMS backends, but many implement enough to be useful to their creator, which is the main point
23:39
<dkubb>
and in DM 2.0 every adapter will have the ability to do everything, whether or not it's native or simulated
23:39
<hassox>
how are you going to achive that?
23:40
<dkubb>
hassox: well, the first thing is the way I'm designing the query/adapter system. queries will be sent to the adapter, and native operations performed, and the remaining operations that couldn't be handled will be executed in ruby
23:41
<dkubb>
hassox: for basic compatibility an adapter will only need to support a "read all" type operation. everything else could be handled in ruby. however, they can add native support for each operation that they can support
23:42
<dkubb>
hassox: I've already got about 90% of the in-memory operations working fine.. from join, to union, etc
23:42
<hassox>
so in the abstract adapter you can do the ruby stuff, which can then be overwritten in a concrete adapter?
23:42
<dkubb>
hassox: basically
23:43
<dkubb>
hassox: not precisely of course, but from the adapter author's pov, they can write the base adapter as a subclass of something abstract, provide a read-all, and then just have their system work with reads. from there they can add create, update, destroy; and then start updating the read method to start handling more native ops
23:44
<dkubb>
ops basically get "shifted" off the stack, and handled natively. whatever is left is handled by the system
23:46
<hassox>
how's veritis going?
23:46
<hassox>
that was it wasn't it?
23:46
<hassox>
veritas even
23:47
<dkubb>
yeah, that's the system. I'm working on making the optimizer so that different adapters could subclass it and override the behavior
23:47
<hassox>
k I have to get out and catch a train
23:47
<dkubb>
but I haven't worked on it this week due to mwrc.. working on a UnitOfWork right now for DM 1.0