Repositories leak across models
Reported by Carl Lerche | February 18th, 2009 @ 01:17 PM
I think one of my biggest pains with DataMapper currently is the fact that models get assigned to repositories way too easily forcing a LOT of calls to repository(:name) { }.
Anyway, there is a bug it seems where a model will always get assigned to the :default repository, which is causing a lot of trouble. See the following code to reproduce:
require "rubygems"
require "dm-core"
DataMapper.setup(:default, "sqlite3::memory::")
DataMapper.setup(:salesforce, "sqlite3:/#{File.dirname(__FILE__)}/salesforce.db")
class Busted
include DataMapper::Resource
def self.default_repository_name ; :salesforce ; end
property :id, Serial
property :message, String
end
Busted.properties
actual = Busted.repositories.map { |r| r.name }
raise "BUSTED: #{actual.inspect}" unless actual == [:salesforce]
Comments and changes to this ticket
-
Dan Kubb (dkubb) February 20th, 2009 @ 11:57 PM
- State changed from “unconfirmed” to “not-applicable”
This is by design. I think you've misunderstood what the purpose of the default_repository_name method is. The default_repository_name is only used to select the repository to use when creating or retrieving an instance outside of a repository() block.
If you are writing code within a merb app, it is possible the repository(:default) block is what is causing this headache for you. It seemed like a good idea at the time (since alot of people were forgetting to use the repository block, and weren't getting the benefits of an Identity Map), but in practice it should probably be removed from the next merb release .. either that, or patched up so that you can specify the repository blocks to wrap every action in.
Perhaps in a future DataMapper we'll have a way to "lock down" the repository for each model, but it won't be in the 0.10.0 release. I would accept a patch to add it pre-1.0, otherwise it will be on my ~> 1.1 TODO list.
-
Carl Lerche February 21st, 2009 @ 08:20 AM
- State changed from “not-applicable” to “confirmed”
This is not by design. There is no repository(:default) block in the example I showed.
The bug happens due to the following line: http://github.com/datamapper/dm-...
Note how in every case, properties(Repository.default_name) will get called, even when you never want it to happen (no matter whether or not the models are always wrapped in a repository block).
-
Dan Kubb (dkubb) February 22nd, 2009 @ 03:30 AM
- Tag set to “bug, repository”
@Carl: I see what you mean now. It was working according to the intended design, but the design itself was wrong. Thanks for being persistent with me on this, I couldn't see the flaw until you pointed to the code line.. and even then I was preparing a response to say basically "that works as intended". Once I explained everything, I saw the flaw and made some corrections.
I just committed a change to dm-core next that I believe should resolve this. I had to make a few modifications to other parts of dm-core to get the default_repository_name to be respected, but I think it's probably alot simpler now. Here are the commits:
http://github.com/datamapper/dm-... http://github.com/datamapper/dm-...
Running the code above with the latest in dm-core/next does not raise any exceptions. Marking this as resolved, but if it is not please add a comment to this ticket and I will reopen it.
-
Dan Kubb (dkubb) February 22nd, 2009 @ 03:31 AM
- State changed from “confirmed” to “resolved”
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Carl Lerche
Dan Kubb (dkubb)