00:57
ashley_moran joined
03:46
<Tass`>
hassox, evening ;-)
03:46
<hassox>
how are you man?
03:46
<Tass`>
in a physics exercise lession ;-)
05:04
<path[l]>
hi, in datamapper I see a find_or_create that tries to find a record and if it doesnt exist, then create it
05:04
<path[l]>
is there an existing behavior to do the opposite
05:04
<path[l]>
first create and if it fails, then do a find
05:21
<dbussink>
path[l]: what is the difference between that?
05:22
<path[l]>
the difference is when Im coding for race conditions. I want to make sure I always have only one record. So I always create. But if it fails I know someone else created it because I can trust the database to handle concurrency
05:27
<namelessjon>
path[l]: I think you have to write it youself, but the first_or_create just combines finding and creating, there's no magic.
05:27
<path[l]>
one more question. Is it possible for me to update a particular record with a condition?
05:45
<kenphused>
i am having an error with bundled merb and do_mysql... "do_mysql.so: wrong ELF class: ELFCLASS64"
05:46
<kenphused>
has anyone else seen this?
05:52
<namelessjon>
path[l]: A condition?
06:04
<namelessjon>
path[l]: You can do something like Model.all(:foo => 'bar').update(:baz => 2) (or update! to do it in the db)
06:07
<path[l]>
namelessjon: what does update! do?
06:11
<path[l]>
so the example I have in mind is if I have a payment and I wanna say payment.update(:baz => 2) only if (:baz == null)
06:11
<path[l]>
but I'd like it to be one sql ideally, so its transactional
06:14
<namelessjon>
path[l]: update! means the query is run directly, rather than fetching the model (so it bypasses validations, amongst other things)
06:15
<namelessjon>
path[l]: So I think to what you want, you'd need something like: Payment.all(:id => @payment.id, :baz => nil).update!(:baz => 2)
06:16
<path[l]>
ah but Im worried that this one will fire 2 sqls?
06:16
<path[l]>
One to find such payments and another to update
06:18
<path[l]>
Im working on an application where we have very high correctness constraints so I need to make sure that if a second process happens to update baz after I get, then I dont update
06:18
<namelessjon>
path[l]: Check out the query logs. That just fires 1 query
06:18
<path[l]>
let me check that
06:19
<slaskis>
has anyone tried using datamapper with macruby?
06:19
<namelessjon>
path[l]: Though I think you'd need to reload the model after firing that.
06:20
<path[l]>
let me try it out
06:24
<path[l]>
oh hmm, thanks let me look at that
06:26
<* namelessjon>
departs
06:39
<path[l]>
hmm crap no. That was 2 sqls
06:39
<path[l]>
there is first a select
06:39
<path[l]>
and then there is an update
06:41
<path[l]>
no it isnt. Looks like Payment.first(conditions).update! and Payment.all(conditions).update! behave differently
06:41
<path[l]>
why is that though
06:49
greeneggandham joined
07:17
<slaskis>
path[l]: what's your conditions?
07:27
<path[l]>
so I have something like Animal.all(:id => @animal.id, :foo => nil).update!(:foo => "bar") ... this is one query
07:28
<path[l]>
so I have something like Animal.first(:id => @animal.id, :foo => nil).update!(:foo => "bar") ... this is one query
08:06
<path[l]>
btw regarding is_state_machine. Anyone know if I can model something like :primed => :blew_up and :primed => :was_dud. ?
08:09
<path[l]>
essentially I'd like two possible transitions from a single state
12:43
<Tass`>
snusnu, funky
12:49
<pjwal>
using :unique => true on a property does not automatically create a unique index on the column in the DB?
12:49
<pjwal>
how is it enforced then?
12:54
<dbussink>
pjwal: in the software layer
12:56
<pjwal>
by actually querying on the field first?
12:56
<pjwal>
querying for a record with that field value i mean
12:57
<dbussink>
pjwal: yeah
12:57
<dbussink>
you can also add a database layer constraint
12:58
<pjwal>
i guess :unique_index is what I am looking for
13:32
<hassox>
quick q about using database.yml with rails3
13:32
<hassox>
how do I setup multiple repositories?
13:32
<hassox>
it doesn't seem to works with the instructions in the generated file :(
13:54
<snusnu>
hassox: what errors do you see?
14:01
<hassox>
it tries to create :default with ''
14:04
<markizko>
Hello guys,
14:22
EccentricLamb joined
14:32
kung_fu_mike joined
14:33
<kung_fu_mike>
anyone here know of the latest docs/how tos/instructions for getting datamapper working under rails 3?
14:45
<kung_fu_mike>
snusnu: perfect, exactly the instruction I had just found and was following
14:45
<snusnu>
markizko: yeah i guess not too many dm users do polymorphic associations very often ..
14:46
<kung_fu_mike>
snusnu: I noticed quite a bit of involvement from you on the rails3_datamapper front. I was in your git account a fair bit
14:47
<snusnu>
kung_fu_mike: awesome, when you hit a wall, feel free to ping me … yeah dkubb kickstarted it under his account initially, and i did most of the dev from then on so i had a fork but always pushed to dkubb's repo too
14:47
<snusnu>
kung_fu_mike: dm-rails is the same codebase with a better name :P
14:47
<kung_fu_mike>
snusnu: thanks a ton man, I appreciate it.
14:48
<kung_fu_mike>
snusnu: ha ha ok. I hadn't taken the time to look up the histories yet
14:48
<markizko>
snusnu: "yeah i guess not too many dm users do polymorphic associations very often" why? I didn't like MK snippet very much because it makes you write 30 lines of code instead of one
14:48
<snusnu>
kung_fu_mike: thx, you're welcome :) i hope that i soon find more time to finish the refactorings i planned .. it's started at
http://github.com/snusnu/dm-config .. which will form the base for all dm-webframework plugins
14:49
<snusnu>
kung_fu_mike: that project will move to the datamapper account too, eventually
14:50
<kung_fu_mike>
snusnu: good to know. I just started this work for a client and I am trying out r3 with datampper over merb. SO I am interested to see how it goes
14:50
<snusnu>
kung_fu_mike: basically, it's for setting dm up with a multirepo database.yml .. and provide common rake tasks … it'll make sure all dm-webframework adapters can share the same code
14:51
<snusnu>
markizko: what most people consider to be a problem with polymorphic associations is the loss of referential integrity
14:52
<snusnu>
markizko: also, most of the times it can be worked around with techniques that keep referential integrity intact
14:52
<snusnu>
markizko: having more tables in the db is not a bad thing per se as long as things are properly designed
14:53
<snusnu>
markizko: also, you can use techniques in dm/ruby land, that allow to cut down the number of model definitions drastically, so that when working with your code, you don't notice that you're having 150 something tables below
14:54
<kung_fu_mike>
snusnu: nice. I am sure I will need all of that in the future like I did in Merb
14:56
<markizko>
snusnu: thanks a lot for the answer, I think I'm gonna play with the multi-table design then
14:56
<snusnu>
markizko: i found dm-is-remixable to be very useful
14:57
<snusnu>
markizko: it's not perfect, and i even started work on a successor for it, which is kinda usable, but untested and not yet done … but i really think it's a nice way of getting around polymorphic associations most of the time
14:58
<snusnu>
markizko: basically, it generates the "join models" for you in memory, so that dm will be able to automigrate them .. and it sets up relationships
15:03
<kung_fu_mike>
snusnu: do you know how to rake the database for different envirnments? I am trying to find it in the docs here ie it used to be rake db:automigrate MERB_ENV=development
15:03
<markizko>
hmm, thanks, that one is great actually. Unlike it's description there in wiki
15:03
<kung_fu_mike>
snusnu: I need to replace that MERB_ENV=
15:09
<kung_fu_mike>
snusnu: got it, you can do MERB_ENV= or RAILS_ENV='
15:09
<snusnu>
kung_fu_mike: yeah, you need to put it before the rake call
15:09
<* snusnu>
me thinks
15:10
<kung_fu_mike>
snusnu: it works fine at the end, but yes I would imagine it to work just as well at the front
15:11
<kung_fu_mike>
snusnu: yeah, just checked
15:11
<kung_fu_mike>
snusnu: both work. I am not sure if it is how rake is parsing the args, or maybe bash
15:11
<snusnu>
markizko: just to make sure, you *are* using / talking of the original dm-is-remixable in dm-more, right? i wouldn't recommend using my version for now ...
15:12
<kung_fu_mike>
and now with datamapper working mike moves on to rspec...
15:12
<snusnu>
kung_fu_mike: heh, don't be afraid of the dark
15:12
<markizko>
snusnu: Yeah, I am not that much keen on using non-stable releases :)
15:12
<snusnu>
markizko: good :P
15:14
<markizko>
snusnu: btw, can dm-is-remixable provide a good :through association?
15:14
<markizko>
Say we've got some tags. We've got tags for comments, tags for posts and tags for people (tags for tags *cough*)
15:14
<markizko>
We need the tagging class to be remixable
15:14
<markizko>
But then would we achieve any result with Person.first.tags?
15:16
<snusnu>
markizko: you would need to "join" them manually inside a method
15:18
<markizko>
I am ashamed I don't know join syntax of DM (never needed with its SEL)
15:21
<markizko>
hm, seems like found it
15:32
<hassox>
snusnu: dude... is it possible to do outer joins?
15:34
<snusnu>
hassox: i'm not entirely sure, but i think there's nothing explicit in the api for it, since it's probably a too rdbms'ish concept
15:46
<markizko>
Isn't "DataMapper::Logger.new($stdout, :debug)" in environment.rb enough for rails application to show DM queries in console?
15:46
<markizko>
I just can't get it to work
15:54
<markizko>
fixed with this one: DataObjects::Sqlite3.logger = Rails.logger
16:08
<siplux>
i have a plugin that needs global options before it can be run. Right now I'm using a setup! method that allows the user to set options before it does its thing. Is there a better option?
16:17
<snusnu>
siplux: what kind of plugin? i mean, what does it do?
16:18
<siplux>
snusnu: an authorization plugin I'm working on. Automagically creates a role,permission,user etc if they don't exist, extends them if they do. However, not everyone wants their models to be "role", "permission" etc, so I want to allow changing that before the plugin tries to set things up
16:19
<siplux>
snusnu: but since its automagical it kinda is problematic, since it does not need to be explicitly including in aforementioned classes
16:21
<markizko>
Found a workaround still weird
16:23
<snusnu>
siplux: sounds like you want the configuration to be run either after setup ran, or after all models have been loaded?
16:24
<snusnu>
markizko: dunno, never used dm with rails2.x
16:24
<siplux>
snusnu: i think after all models have been loaded would make the most sense - it needs to know whether or not it should be creating new models i think
16:24
<siplux>
snusnu: actually ... i'm wondering if might be better to just force the user to explicitly include it in a class and set the options there since it would require the same amount of typing. And generally people will always have an existing user class.
16:26
<siplux>
snusnu: but for my own edification, is there a wayto tie into that event "after models loading"?
16:26
<snusnu>
siplux: yeah that sounds better, just provide the functionality in modules that can be included or class methods that activate them
16:28
<snusnu>
siplux: well, there are no explicit hooks now for things like after_setup or after_models_loaded … mainly because dm itself doesn't strictly need it .. i only recently talked to dkubb about adding some hooks tho, but it's not yet decided .. it's mostly relevant for plugins and i felt the need to have after_setup hooks myself already
16:28
<snusnu>
siplux: concerning the after_models_loaded hooks .. that really depends on how you "configure" your dm application, like, if you're using a webframework, or do all the setup code yourself
16:31
<snusnu>
siplux: and that code needs all models to be preloaded, because only when that code has run, you can be sure that all properties that are lazily created by calling #belongs_to or #has are really established
16:31
<siplux>
snusnu: couldn't that be made to be framework agnostic? I mean DM internally must know when all models are loaded in order to setup relationships?
16:31
<snusnu>
siplux: and that …. well … is a bit of a "problem" with how rails lazily loads model code … which leads to some weird behaviors where the reloading done by rails wipes out already included behavior and such
16:31
<snusnu>
siplux: that will be part of dm-config
16:32
<snusnu>
siplux: oh, i was talking to kung_fu_mike about dm-config earlier on … basically, it's all the configuration for a dm (multirepo) app bundled into a gem
16:33
<snusnu>
siplux: that will be used by dm-rails,dm-merb,dm-sinatra,dm-whateverwebframework
16:33
<siplux>
snusnu: gotcha, that sounds promising
16:34
<snusnu>
siplux: i should finally get at finishing that refactoring … all the code was originally extracted from dm-rails .. and then refactored .. i'm not yet really happy with it tho
16:34
<snusnu>
siplux: once it stabilized, that will be pushed to the datamapper account
16:36
<siplux>
snusnu: which configuration is it intended to store?
16:37
<snusnu>
siplux: it's basically a wrapper over a typical multirepo/multienvironment database.yml … a few objects that model that configuration .. a set of methods to setup dm on all these repos in the respective environment .. and a set of rake tasks to create/delete/automigrate the database as specified in the database.yml
16:38
<snusnu>
siplux: so that you can use it to setup any kind of "serious" dm app .. be it a web app or not
16:40
<siplux>
snusnu: ah, thanks
16:52
<kung_fu_mike>
Does anyone know about auth in rails 3? is everything going to warden? or is there some rails-auth gem somewheres?
16:54
<siplux>
kung_fu_mike: no idea - I used warden since it was more agnostic. their docs are poor though
16:54
<kung_fu_mike>
oh fun