dkubb changed the topic of #datamapper to: Datamapper v1.2.0 | Mailing List: http://is.gd/aa9D | Logs: http://is.gd/qWAL7V | DataMapper 2 Renamed to ROM, see #rom-rb for development
<dkubb>
theCrab: and if you do submit a patch after testing this works for you, please make sure it includes a spec that fails without the change
<theCrab>
dkubb: i'll do that
zombor has quit [Remote host closed the connection]
solnic has joined #datamapper
<theCrab>
dkubb: I haven't written a test for it, i will In a minute but i changed enumerable.all? { |entry| valid_for_subject?(entry) } TO enumerable.any? { |entry| valid_for_subject?(entry) } and it fixed my issue with the correct SQL generated
<dkubb>
theCrab: sweet
<dkubb>
theCrab: yeah, it seems like a simple fix. my original intention with that was to disallow an invalid query, but the query should still be valid if at least one of the id's is valid
<theCrab>
dkubb: FROM "people" WHERE "id" IN (23, NULL) ORDER BY "id"
<theCrab>
dkubb: so that was intentional?
<theCrab>
dkubb: I don't know if i should make a PR for it. Is there a reason why it should be the way it is now? security etc
<dkubb>
hmm
<dkubb>
theCrab: what I would probably do is filter out all the invalid subjects
<dkubb>
theCrab: in the constructor for that object maybe you can filter it out
mikecmpbll has joined #datamapper
<theCrab>
dkubb: very true, hmmm how though. My case is only when i pass nil to it. What are the other invalid possibilities?
<dkubb>
theCrab: I think we would definately *not* want to use NULL within an IN() clause
<theCrab>
dkubb: let me see where the sql IN() is constructed so i can flush out all the NULL's
maxzda has quit [Ping timeout: 264 seconds]
<dkubb>
theCrab: it is valid to use NULL in an IN() clause .. just not in this specific case
<dkubb>
theCrab: the property objects know what is and is not valid
<dkubb>
theCrab: what I would do is filter them out in the *same* object where this happens
<theCrab>
So say I should probably filter my request right?
<dkubb>
you could, but I would fix it in the dm code
<dkubb>
obviously, because I would like to fix this class of bug ;)
<Cinchy>
[URL] mysql - DataMapper can't delete record because of relation - Stack Overflow
<Eiam>
so it looks like If i destroy my relationships first, I'm good. and testing confirmed indeed
<Eiam>
if I destroy my has n relations, then I can destroy the object
<Eiam>
so I guess I should wire that up in a transaction of some sort
snusnu has quit [Quit: Leaving.]
<namelessjon>
Eiam: Then you are using dm-constraints, possibly through "require 'data_mapper'"
<dkubb>
you can also define your relationship with constraint: :destroy
<Eiam>
namelessjon: hmm okay, I don't see it in the gemfile
<dkubb>
that'll "cascade" and delete the other objects
<Eiam>
anyway I can ask the model or data mapper if it is using constraints?
<Eiam>
namelessjon: according to that stack overflow page, if I use constraints I have to clean up the associations table manually
<namelessjon>
Model < DataMapper::Constraints
<dkubb>
Eiam: I made it so the constraint system was strict by default. that means you can't accidentally "orphan" an object by deleting it's parent.. you have to delete the children first, then delete the parent object. however, there are options to configure what you want to have happen when a parent is deleted
<Eiam>
hm okay, so use data mapper constraints magic, or build a transaction
* Eiam
ponders options
<Eiam>
my boss just said "avoid data mapper magic, build a transaction"
<dkubb>
one thing to keep in mind if your children have children of their own, the system will prevent those from being deleted
<Eiam>
but I'm rather fond of simple magic
<dkubb>
heh
<dkubb>
it's not really magic. it uses database constraints, which are kind of anti-magic
<Eiam>
dkubb: yes, indeed, some of the higher level objects have children that have children
<namelessjon>
That's not magic, I think it gets enforced on the database level
theCrab has quit [Quit: Sleeping -_-]
<dkubb>
it does. datamapper does some stuff at the object level, but if you were to bypass the dm stuff by using destroy! you'd see how the database would prevent you from orphaning a record and corrupting the database
theCrab has joined #datamapper
<dkubb>
unless it's valid for a child to exist without a parent. I can't claim to know your domain
<Eiam>
dkubb: If i just set , :constraint => :destroy on all the has n :some_models, then a delete on the top level would cascade down
<dkubb>
in general though if you reference another row in another table, you want that other record to exist
<dkubb>
Eiam: :constraint => :destroy will cascade to the child. if that child has dependents of it's own you would want to specify those, until you get to the leaf nodes of the object graph
<Eiam>
right, so in order to support a cascading delete by deleting the top level model, every 'has n' relation needs to have the constraint :destroy so it'll continue deleting the whole tree
<Eiam>
its not valid for any model to exist without the top level model
<Eiam>
so if the top level is gone, everyone has to go.
<dkubb>
Eiam: exactly
<Eiam>
okay, just wanted to make sure I understood it correctly
<dkubb>
in DM, relationships *on* the parent to a child use has(), while relationships on the child to a parent use belongs_to()
<Eiam>
namelessjon: yes, it appears constraints is indeed there even though its not specified.
<dkubb>
so you want to specify :constraint => :destroy on the has() relationships
<Eiam>
dkubb: right
<Eiam>
(can't believe I just understood this)
<Eiam>
dkubb: thanks =)
<dkubb>
Eiam: when you are using dm-constraints it defaults to using :constraint => :protect if you don't specify anything else
<dkubb>
it's the safest option. I'd rather have it trip someone up so they have to ask here or somewhere else, than for DM to not define strong constraints
<onewheelskyward>
So, by default, I can't delete something with a belongs_to if the parent relation exists?
<dkubb>
I just wish I was able to go strict in other cases, like have properties default to { required: true }
<namelessjon>
onewheelskyward: Other way around
<onewheelskyward>
ah, yes, my mistake.
<namelessjon>
onewheelskyward: You couldn't delete the parents
<dkubb>
onewheelskyward: you can't delete a parent if it has children that depend on it
<dkubb>
if nothing depends on the parent, then of course you can delete it
<onewheelskyward>
Right.
<onewheelskyward>
No dependencies, no problems.
<dkubb>
it's to prevent orphan records
<dkubb>
which is a common data integrity problem
<onewheelskyward>
Yep. Though these days I find I really don't delete anything.
theCrab has quit [Ping timeout: 268 seconds]
<dkubb>
me either really
<onewheelskyward>
In fact, my major datamapper app accesses a legacy database that's managed by doctrine. So I really don't do much to it at all.
<dkubb>
another thing the constraints do is force you to create a parent before a child, which is not really a common problem when people use autoincrementing keys
<dkubb>
I didn't enable cascading by delete in DM because in some database schemas a delete of one object can cascade across half the database ;)
<onewheelskyward>
yikes. Also? Awesome. Like rolling thunder.
<dkubb>
heh
<dkubb>
I'm sure people would've loved that
<onewheelskyward>
I wonder if there's a visualizer library for that kind of thing.
<dkubb>
you could probably rig one up using graphviz
<dkubb>
I have before, when I was writing the relationship code
<dkubb>
it was very much a one-off kind of thing. I'm positive I don't have the code anymore
<dkubb>
if anyone is interested in writing a visualizer for ROM I would be glad to help out in #rom-rb
<dkubb>
or for #datamapper.. graphviz is pretty easy to use
<dkubb>
I use it to visualize the tree I built up for a query in axiom.. also for the optimizer to view the tree before and after
zombor has joined #datamapper
zombor has joined #datamapper
<namelessjon>
iirc, there's a dm-vizualizer somewhere
zombor has quit [Remote host closed the connection]
<onewheelskyward>
ROM? Ruby On Mapper?
<onewheelskyward>
Read Only Memory?
<dkubb>
Ruby Object Mapper
<dkubb>
we renamed DataMapper 2 because we didn't want people to get confused, it uses a completely different approach and is actually a true Data Mapper
<dkubb>
DM1 is an Active Record with basic mapping (rename) support
<dkubb>
I still use DM1 in new projects, but I hope to be able to transition to ROM once we get the main pieces working
mbj has joined #datamapper
<onewheelskyward>
Oh yeah, I remember those discussions happening months ago. I missed the decision. :)
<dkubb>
that quote on the front page is a bit funny. Sam was only really involved for the first few months of DM and then I took over
<xybre>
Since ROM is for arbitrary Ruby collections, it should be pretty easy to wire in any date store, right? I ponder this because I can't really see myself tolerating a full SQL database like Postgres or MySQL again when I have the choice not to.
Datenkleptomane has joined #datamapper
<xybre>
Oh, that was meant for #rom-rb
zombor has joined #datamapper
zombor has joined #datamapper
zombor has quit [Changing host]
v0n has quit [Ping timeout: 246 seconds]
zombor has quit [Remote host closed the connection]
solnic has quit [Quit: Leaving...]
mbj has quit [Quit: leaving]
snusnu1 has joined #datamapper
snusnu1 has quit [Client Quit]
kurko__ has quit [Quit: Computer has gone to sleep.]
banditron has quit [Remote host closed the connection]
kurko__ has joined #datamapper
dkubb has quit [Ping timeout: 240 seconds]
knowtheory has joined #datamapper
snusnu has joined #datamapper
<snusnu>
!memo mbj can you point me to places where substation uses class injection? please use the decentralized_dispatch_table branch for reference