Hi, > I upgraded a merb project to 0.9.8 recently from 0.9.6 and lots of specs > started failing, that were working before. The merb controller method > #resource stopped producing meaningful urls when passed an object. I posted > about this on the merb list (as fate always has it) right before I found out > that this was a known dm bug.
This is resolved in dkubb/dm-core, which is our edge branch. Critical fixes are backported to the stable sam/dm-core branch immediately, non- critical fixes are not. Of course what is critical and non-critical is a bit subjective, but ultimately it is decided by the person committing the code to dkubb/dm-core. If someone disagrees, they are welcome to backport it themselves. If no-one's done it yet, I have to assume it's not a big enough pain point or they haven't hit the specific problem yet. If someone makes a fix that needs to be applied to sam/dm-core, please send me a pull request or log a ticket and I will commit it. If it is serious enough, or affecting a large number of people, I will do a gem release relatively quickly. > The other thing that started happening is that the #size methods on > one-to-many proxies stopped working. This is a known issue in sam/dm-more/dm-aggregates and will be resolved in the next gem release. I've only heard about it from 2 or 3 people so IMHO it wasn't serious enough to require an immediate gem release. > I am still waiting for datamapper to get the basics > that I need for an app and for them to be stable. I really want the latest > stable gem to be stable, and not break my gems. This is something we are working on right now: http://github.com/dkubb/dm-core/wikis However, it's stalled a bit in the last week or two with the holidays, and we need the people who committed to working on the classes to finish them, or for someone to take over the classes. I will be doing a post in the next few days to try to bring the momentum back to what it was just before the holidays. > I also want datamapper to > handle things like building (and saving when the parent is saved) the rich > join record in a has n, :through => Model relationship. This is something I am working on personally. It's actually far more difficult in DM than any other ORM that I am aware of, due to our ability to handle multiple repositories. For example, a many to many association, at minimum, affects 3 models. What if those three models are in different repositories, or two are in one, and one is in another? Many to many can actually span 3 or more models.. so what if there are 5 models, and 5 repositories? When the models are in the same repository some storage engines can use joins for reads, while others can't, and how do we handle this transparently? I think you get the gist. I'm trying to get my head wrapped around the logic and design an approach that is straight forward to code and maintain, but it's more difficult than I first imagined. > I could go on, but no one knows better than the project contributors that > there is a lot on the wish list. Right. The most constructive approach people can have right now is to ask how they can help. At any given time there's only maybe, at most, 4 or 5 regular contributors, but DM is such a large project that we really need more than that to keep up. With DM being all volunteer, it really is dependent on people's personal time, which can fluctuate. It would be sweet if there was some corporate sponsorship to keep things more consistent, but baring that we need people who care about the project to step up and take over tickets, or volunteer to maintain a dm-more gem for example. I've been sitting on a mailing list post for the past couple of weeks to give people an idea of how they can help us, and I will put it into a real post within the next day or so. In the meantime, here's the gist of what I was going to post: http://gist.github.com/33615 > Right now the projects seems a little lost. Maybe it just looks that way > because I haven't been paying close enough attention for the last many > months. If you were unaware of dkubb/dm-core and only watching sam/dm-core it might appear that way. In the last couple of months we've stepped up gem releases, resolved nearly 100 tickets in Lighthouse, made probably a hundred commits to dkubb/dm-core adding thousands of specs and cleaning up the internals alot. In fact if you run dkubb/dm-core right now, using every adapter, it will execute 15,000+ specs.. sam/dm- core has 1/10th that number. We still have a ways to go with dkubb/dm-core before I am satisfied, but I'm confident we're going in the right direction. > At any rate, seems like there isn't sufficient regression specs for > the refactor in progress. I was wondering which parts of datamapper the team > looks at as fully refactored and stable. I was also wondering if there is a > plan for the wish list and the project in general. I think I need to take responsibility for not giving people enough status updates on the project. I'm not too good at tooting my own horn :) Let me just say this: When DataMapper 1.0 is released it will likely be considered one of the most well specced ruby gems ever made. Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
