00:00 <d-snp> on_save { if not type.is_supported? then serialize else do_whatever_it_is_that_supported_types_do end }

01:00 <postmodern> did lighthouseapp.com just die?

01:02 <postmodern> yeah not getting a DNS respond from them

01:06 <postmodern> ah there we go

01:51 <dbussink> d-snp: you still there?

05:47 <path[l]> hi, Im trying to write a db column that holds arbitrary data. I was trying to use json. However I get an error I dont understand when I try and store {"a" => "b"}

05:47 <path[l]> NoMethodError: undefined method `except' for #<JSON::Pure::Generator::State:0x42847574>

05:59 <path[l]> whats the best serialization type to use if I want to store a hash

08:01 <bphogan> hey all, having a little difficulty with something simple - anyone have an example of doing a save in an after_save? I want to create a permalink url based on the record id.

08:14 <path[l]> hi

08:23 <snusnu> bphogan: what problems are you facing?

08:24 <bphogan> snusnu: I don't actually know much about datamapper. In ActiveRecord, if I called save in an after_save it would do bad things, and so there was a private method I'd use to not invoke callbacks. I can't find any DM examples of doing something like this other than overwriting save and calling super.

08:25 <bphogan> not sure if that's the approach I should use.

08:26 <bphogan> basically I want to create a slug for the url cos I don't wanna use ids (afraid I'll run out if I just use ints)

08:29 <namelessjon> bphogan: You're honestly expecting more than 9223372036854775807 urls?

08:29 <bphogan> namelessjon: let's just say that *I* am not.

08:30 <snusnu> bphogan: i guess you'll potentially run into problems if you call save in after/before save yeah .. i'm not aware of anything particular to prevent that .. i#m no fan of hooks, i overwrite save and call super normally

08:30 <bphogan> namelessjon: :)

08:30 <Tass`> bphogan, #save!

08:30 <bphogan> snusnu: oh ok well I am fine with doing that, I just wanted to know if that was frowned upon or standard practice.

08:31 <snusnu> bphogan: also, dm will get "proper" lifecycle hooks at some point before 1.0 .. the currently used extlib/hooks are too general and have some problems

08:31 <snusnu> bphogan: but yeah, as Tass` pointed out, basically you have save() and save!() the latter not running any valdiations and callbacks

08:31 <namelessjon> bphogan: Ah,one of those situations. (Out of curiousity, how do they expect to cope when you run out of integer ids on the backend? ;) )

08:31 <bphogan> snusnu: Tass` I like that

08:32 <Tass`> bphogan, but without validations either

08:32 <bphogan> Tass`: yea I saw that but that's fine. Cos it will not need validations at the point where I'll be using it.

08:32 <bphogan> at least, not for this :)

08:32 <namelessjon> bphogan: Also, update(!) might work, too.

08:36 <d-snp> dbussink: I'm here

08:37 <bphogan> namelessjon: re: running out of ints... sigh I know. But I suspect they're going to do something stupid on the db side and not use regular ints. I'm just helping out, it's not my project.

08:38 <bphogan> (and by stupid, I mean it will probably be a string or something stupid.)

08:41 <bphogan> Anyway, thanks for the save! tip.

08:51 <dbussink> d-snp: did you look at solnics refactor for properties?

08:59 <d-snp> dbussink: no I'm just using the release

09:00 <d-snp> is the solnics refactor in master?

09:01 <dbussink> d-snp: no, not yet, but it has a much improved property implementation

09:01 <dbussink> dkubb is planning on merging it soonish

09:01 <d-snp> ok

09:02 <d-snp> I'll check it out :)

09:06 <solnic> d-snp: yeah "ArgumentError: +type+ was Hash, which is not a supported type" will go away soon :)

09:07 <d-snp> cool

09:07 <d-snp> after the Hash, there will be an error ArgumentError: +type+ was Episode

09:08 <d-snp> which is a datamapper resource, will this result in awesomeness solnic? :)

09:08 <solnic> d-snp: basically everything that derives from DM::Property::Object will work, have a look at https://gist.github.com/5a99710131190c128f6e

09:09 <solnic> d-snp: embedded resources will be supported too, but that's a different story :)

09:24 <github> dm-more: master snusnu * 5024951 (1 files in 1 dirs): [dm-timestamps] require 'dm-core' because we need it - http://bit.ly/dqdl1e

09:28 <d-snp> solnic: is that a work in progress or actually implemented in your branch?

09:29 <solnic> d-snp: property refactor is 95% done in my fork

09:30 <d-snp> ok

09:34 <Tass`> is it just me or does github forkqueue suck atm?

09:42 <path[l]> whats a slug?

09:42 <Tass`> path[l], iirc blub

09:42 <Tass`> ehh blob ;-)

09:43 <path[l]> oh

09:43 <Tass`> but not sure.

09:43 <path[l]> so it could be any data structure?

09:47 <snusnu> a slug in that context is a SEO friendly representation of an ID in an URL

09:48 <snusnu> at least that's the only context i ever heard the term slug being used

10:02 <path[l]> oh

10:03 <path[l]> Im trying to figure out what the best structure to use is to store a hash as it is

10:03 <Tass`> path[l], nosql? ;-)

10:04 <Tass`> path[l], two columns, 1x key, 1x value

10:04 <path[l]> no I mean there's just one extra table where I just wanna store some data

10:04 <path[l]> so since Im using datamapper Id like to know what type the value column should be

10:06 <Tass`> path[l], well, you could use Object

10:06 <path[l]> Object is a datamapper type?

10:06 <Tass`> yep

10:07 <Tass`> #

10:07 <Tass`> # Object, (marshalled)

10:07 <path[l]> ah

10:07 <path[l]> I was thinking something like json

10:07 <path[l]> or something

10:07 <Tass`> works as well

10:07 <path[l]> sinc my data is a hash

10:07 <Tass`> Yaml exists as well

10:07 <path[l]> but json seems to want an array of hashes

10:48 <careo> Tass`: real?

12:53 <tjholowaychuk> I have to iterate lots of records and access relations similar to this user.site.id, of course loading their Site each time

12:54 <tjholowaychuk> when querying all users can I join the sites on to prevent all those selects?

13:04 <snusnu> tjholowaychuk: standard SEL should take care of this as long as you only "nest" one level

13:06 <snusnu> tjholowaychuk: the syntax for joining in stuff (like AR's :include option) would be to just add a: "relationship_name.property_name" => value query option

13:06 <tjholowaychuk> might be something else going on then. I have about 900 records selected initially, but then when they are iterated on and I am accessing

13:06 <tjholowaychuk> various properties, I have a total of over 900 queries

13:07 <snusnu> tjholowaychuk: btw, SEL would probably only work right with latest codes (or at least a 0.10.x release)

13:07 <tjholowaychuk> seems to be working, im on 0.10.2

13:07 <tjholowaychuk> not sure what is causing so many crazy queries though holy haha im checking out the log ill touch back on that

13:25 <grandy> hello, just wanted to ask about indexes... it's still necessary to specify :index => true in the property, correct?

13:28 <grandy> having trouble finding docs on indexes

13:29 <grandy> does anyone know if association created columns are automatically indexed? such as foreign keys?

13:33 <grandy> i just checked and it looks like only serial cols get an index by default?

13:45 <namelessjon> grandy: FKs are too, if you just use 'belongs_to :foo' (and don't define a :foo_id property)

13:46 <grandy> namelessjon, ahh ok, htanks

13:47 <grandy> namelessjon, do you know if indexes are added on DataMapper.auto_upgrade! if the schema already exists?

13:48 <namelessjon> grandy: They're not (at present).

13:49 <grandy> namelessjon, do you know if there is a way to trigger their creation? Or do I have to create them manually?

13:50 <namelessjon> grandy: Manually, or you might be able to with dm-migrations.

13:51 <grandy> namelessjon, ahh ok... i'll investigate that ... thanks

15:14 <tjholowaychuk> how can you kick a query without doing something dumb like User.first.friends.map

15:18 <tjholowaychuk> yikes..

15:18 <tjholowaychuk> turns out queries are not my issue at all.. its iterating the records, even with only 1800 records a simple #map takes a good 8 seconds

15:27 <Tass`> careo, as property

15:35 <mouse-_> hey, if i just need an empty model can i m=Model.new without m.save & nothing happens to the db?

15:36 <careo> Tass`: I am so confused. did you mean to say that to me originally, or someone else? heh

15:36 <Tass`> careo, no idea.

15:37 <careo> Tass`: that makes two of us.

17:41 <cored> i need some feedback regarding how this tutorial is doing

17:41 <cored> http://github.com/cored/maskeet.git

17:41 <cored> everything is in the wiki

17:41 <cored> anyone

18:01 <careo> is anyone using dm with merb 1.1.0rc1 and bundler? I'm getting "uninitialized constant DataMapper::Serialize::Model" when simply trying to run rake in a freshly-made merb app

18:29 <careo> ahh. bundler 0.9.7 is the answer, not the latest.

19:29 <snusnu> hey namelessjon, you around?

19:29 <postmodern> snusnu, hey you can kill my latest bug

19:29 <postmodern> snusnu, realized i made a typo

19:29 <snusnu> hey postmodern, i already read your comment :)

19:29 <postmodern> excellent

19:30 <snusnu> postmodern: mind a quick question?

19:30 <postmodern> shoot

19:31 <snusnu> so, i'm working on a patch for dm-more that adds a require 'dm-core' statement to any of the plugins that actually use a constant defined by dm … i mainly need to do that because of bundler, which still doesn't respect the order in which gems have been declared, iirc

19:31 <snusnu> so my "question" really is .. what's your opinion on that?

19:31 <snusnu> i mean, actually i think it's *right* to always require what's needed

19:31 <postmodern> i like it

19:32 <postmodern> that's exactly how i write code

19:32 <postmodern> require wont require files twice, so rubyists should make use of this

19:32 <postmodern> whenever my code uses modules/classes, i excplitly require tem

19:32 <postmodern> *them

19:32 <postmodern> even if they are probably already loaded

19:32 <postmodern> makes the code explicit and obvious

19:33 <snusnu> exactly, the way i think about it, it's just like making a lib cherry pickable .. the gem should require everything it needs so that it won't raise errors when operated

19:34 <snusnu> even if one would probably never just require "dm-timestamps" without dm-core .. i would always add the dm-core statement, even if i know dm-timestamps does that for me already

19:34 <postmodern> you could also directly require what you needed from dm-core

19:34 <postmodern> like dm-core/model or dm-core/resource

19:35 <snusnu> yeah, although that would require dm-core to be "cherry pickable" .. and i'm not sure if that would make any "sense" ?

19:35 <snusnu> i mean, heh ..

19:35 <snusnu> hmm

19:36 <snusnu> i guess it's fine to take it to the conceptual level where the "complete gem" is available for the other one to work .. it's fair to assume the default entry point to that gem i think

19:39 <snusnu> the question came up when i arrived at dm-types btw .. i think it'd be consistent to require dm-types in every type that uses a dm constant .. however, in a real world app you would probably never use a dm type outside of a dm resource .. in which case ruby would bail out before arriving at the type, in case dm-core hasn't been required before

19:40 <snusnu> so this really probably is only for the sake of bundler (and consistency, and imho good style .. but that's the questionable part for me)

19:46 <postmodern> i end up taking on the Turtles-All-The-Way-Down approach

19:46 <postmodern> that every file in my gem can be a possible entry point

19:47 <postmodern> every file requires other files it may need

19:47 <postmodern> so external libraries can require any file from that library

19:58 <snusnu> postmodern: http://github.com/snusnu/dm-more/commit/45af49f64c9dee75ded7af49fe4502d163384796

19:58 <snusnu> postmodern: yeah, that's probably the cleanest approach

20:01 <postmodern> snusnu, nice

20:04 <snusnu> postmodern: i'll merge it into master hopefully tomorrow or the day after .. together with the rest of the AS branch

20:04 <postmodern> snusnu, very nice

20:05 <postmodern> snusnu, should be execiting

20:05 <postmodern> snusnu, i guess after you merge the AS stuff I'll need to go over my stuff and rip out extlib as well

20:06 <snusnu> postmodern: the goal is to keep extlib compat around for quite some time still .. we need that for merb at least … but yeah, it's good to switch to AS sooner than later

20:06 <careo> snusnu: cool. I was just bitten by that in fact

20:07 <snusnu> careo: merb/extlb/AS ?

20:07 <careo> snusnu: bundler and dm

20:07 <snusnu> careo: ah ok

20:08 <snusnu> careo: well, as you probably saw, the patch is in the AS branch only for now :/

20:08 <careo> snusnu: I "fixed" it by doing the requires in init.rb myself

20:08 <snusnu> yeah, feasible workaround for the time being

20:10 <snusnu> careo: actually, i'd like my requires explicitly in the init.rb (or "even" a rails_app/config/application.rb) .. i'm not yet sold on the "bundler should respect the order in which gems have been declared in the Gemfile" issue

20:11 <careo> snusnu: yeah. I mean, the "order gems have been declared" was the )#($*#)$ing problem with dependencies.rb in the first place!

20:11 <snusnu> careo: the more i urge myself to think of the Gemfile as executable code, the more i can understand why it's probably not so bad (or even a good idea) .. but some part of me still thinks it's for the lazy

20:12 <careo> snusnu: but I thought part of the whole purpose of bundler is that it does all of its magic in a smarter way

20:13 <snusnu> careo: otoh, it's of course not really dry to have it in the Gemfile and then app code again .. otoh, it's two different things … one is to alter the loadpath (and activate a gem) .. that's Bundler.setup and the Gemfile … the other part is *require* .. so it doesn't really violate dry imho

20:13 <snusnu> careo: how do you mean smarter way?

20:13 <careo> snusnu: what you said. kind of. :)

20:13 <careo> let you list gems and have bundler figure out the best deps

20:14 <careo> so you don't get into that "x activated y" hell

20:14 <careo> but thinking about neverblock

20:14 <snusnu> careo: that's what it does already … but it does that when *activating* the gems .. thus manipulating the loadpath .. in Bundler.setup … Bundler.require is a whole different story

20:14 <snusnu> careo: it needs to rely on the gems doing the proper thing

20:15 <careo> yeah

20:15 <snusnu> careo: the Gemfile feels more like a config file to me

20:15 <snusnu> careo: i wouldn't expect it's order to be relevant

20:15 <snusnu> careo: also, a call to *gem* .. doesn't mean a require to me

20:16 <careo> I dunno. I mean, thinking about how neverblock does its thing. it's super sensitive to require order. especially if you want it to work with openssl

20:17 <snusnu> careo: never used that … but imho that's one more point to leave explicit control "in the code"

20:18 <careo> snusnu: yeah.

20:18 <snusnu> careo: and there are also bundler groups .. i just have the feeling that "respecting the order" will be confusing to me

20:19 <careo> snusnu: totally.

20:19 <careo> I don't want to ever have to micro-manage the order of lines in my gem list again :)

20:20 <snusnu> careo: imho it shouldn't care about that *at all* … these are mostly problems that need to be fixed upstream anyway (like in this case with dm-more) … and Bundler.require is for the lazy :P

20:23 <careo> yeah.

20:26 <snusnu> careo: one last point that comes to mind is a situation where a gem decides to act differently based on the presence of another gem … that's no upstream problem, but still, it's better to have the require calls explicitly in the code, than to have the gem calls in the Gemfile

20:26 <snusnu> now i'm done :P

20:28 <careo> hehe

22:26 <path[l]> http://datamapper.rubyforge.org/svn/trunk/lib/data_mapper/associations.rb <---- this file suggests I should have a build association method. Is this the latest? or really old

22:29 <postmodern> for extlib's Object.get_full_const, does ActiveSupport have a similar method?

22:29 <postmodern> path[l], i don't think the rubyforge SVN has been used for many years now

22:29 <path[l]> ah

22:30 <postmodern> the 'data_mapper' directory is very old

22:30 <postmodern> that got renamed to 'dm-core' a while back

23:12 <path[l]> ok