[ANN] DataMapper 0.10.0 RC1
0 views
Skip to first unread message
Dan Kubb (dkubb)
Jun 19, 2009, 2:36:35 PM6/19/09
to DataMapper
I am pleased to announce the release of DataMapper 0.10.0 Release
Candidate 1.
For the impatient, here are the command line instructions to install
it:
Install
-------
1) Add gems.datamapper.org as a gem source:
gem sources --add http://gems.datamapper.org
2) Install the dm-core gem:
sudo gem install dm-core
3) (OPTIONAL) Install whatever dm-more gems you use, eg:
sudo gem install dm-aggregates
sudo gem install dm-constraints
sudo gem install dm-migrations
sudo gem install dm-serializer
sudo gem install dm-timestamps
sudo gem install dm-validations
sudo gem install dm-types
4) (OPTIONAL) Install the database driver, or adapter you plan on
using, eg:
sudo gem install do_sqlite3 # or do_mysql/do_postgres
NOTE: dm* and do* gems should be at version 0.10, while extlib will be
at version 0.9.13.
NOTE: the DO gems probably need more testing with Windows, which we
are
doing right now. Ted Han will post a follow-up to this thread with
the
results of the test.
What's New
----------
The largest difference between the new 0.10 series and the new 0.9
series
is not so much the API changes, it's the approach we've taken to
developing it. Rather than add a ton of features and bloat, we took a
step back and decided to address two of the weakest areas in DM: specs
and documentation.
We began documenting the public and semipublic APIs for each method.
(A
public method is the part of the API that you'd be using as a
DataMapper
user, while a semipublic API is more for plugin authors). We
documented
and specced the *intended* behavior of each method, not necessarily
the actual behavior, and began working towards making those specs
pass.
As the spec coverage grew, we began to refactor some of the DM
internals
to make things more clear, but we tried not to get carried away with
this
unless it was necessary to make things work. In some cases, like with
relationships/associations, to match the intended behavior we had to
rewrite nearly all the code.
Even with us taking a conservative approach to rewriting internals,
there
were 2-3x more commits and changes between the 0.9 and 0.10 series
than
there were since the beginning of the DataMapper project and 0.9, so
this is a large update.
We also rewrote the Adapter API to make things easier for adapter
authors
to make full use of the DataMapper features. In the past many
adapters
only implemented partial behavior because the backends were limited in
what they could provide in terms of matching, sorting and limiting the
results. In those cases we're now providing helper methods to fill in
any holes in the storage engine capabilities.
What's left
-----------
While working on the 0.10 series we identified a number of areas of
improvement, but to avoid getting distracted we've added them to the
wiki: (Feedback welcomed)
http://wiki.github.com/datamapper/dm-core/roadmap
Many To Many associations are much more stable than in the 0.9 series.
One of the main reasons we decided to do this release is that we
noticed
we started spending more time telling people reporting bugs to
"try it with dm-core/next", and more often than not it did fix the
problem. Are we done with Many To Many associations? No -- there are
still a few known issues with edge cases -- but we're 95% of the way
there.
We still need to continue documenting more of the public and
semipublic
using YARD format. Also over the next few months we're going to work
on increasing the coverage of the specs even further.
What we need
------------
We're now at the point where we need some real-world testing outside
of
a few dedicated people who have been tracking edge. If you have a
spec
suite, then please upgrade DataMapper, run your specs and report any
issues you encounter. (Fix/ignore the deprecation warnings of course)
DataMapper is a pretty difficult project to fully spec due to it's
flexibility, and ability to use one of dozens of storage adapters. If
you do encounter a use case that we haven't covered, please submit a
ticket and we'll work on adding it to our spec suite.
Report any issues you find in IRC, on the mailing list, or in the
tracker:
IRC: #datamapper
Mailing List: http://groups.google.com/group/datamapper
Bug Tracker: http://datamapper.lighthouseapp.com/projects/20609-datamapper
Please search through the existing tickets prior to submitting, but
when in doubt please create a ticket. I would rather have to sort
through dupes or tickets that turn out to be resolved/invalid than
for a valid bug to go unreported.
Likewise if you're experiencing any problems with 0.9.x, please try
the RC1 and see if it resolves your problem. If it does, and you've
created a ticket for it, please add a comment to the ticket so we
can close the ticket.
--
Dan
(dkubb)
Candidate 1.
For the impatient, here are the command line instructions to install
it:
Install
-------
1) Add gems.datamapper.org as a gem source:
gem sources --add http://gems.datamapper.org
2) Install the dm-core gem:
sudo gem install dm-core
3) (OPTIONAL) Install whatever dm-more gems you use, eg:
sudo gem install dm-aggregates
sudo gem install dm-constraints
sudo gem install dm-migrations
sudo gem install dm-serializer
sudo gem install dm-timestamps
sudo gem install dm-validations
sudo gem install dm-types
4) (OPTIONAL) Install the database driver, or adapter you plan on
using, eg:
sudo gem install do_sqlite3 # or do_mysql/do_postgres
NOTE: dm* and do* gems should be at version 0.10, while extlib will be
at version 0.9.13.
NOTE: the DO gems probably need more testing with Windows, which we
are
doing right now. Ted Han will post a follow-up to this thread with
the
results of the test.
What's New
----------
The largest difference between the new 0.10 series and the new 0.9
series
is not so much the API changes, it's the approach we've taken to
developing it. Rather than add a ton of features and bloat, we took a
step back and decided to address two of the weakest areas in DM: specs
and documentation.
We began documenting the public and semipublic APIs for each method.
(A
public method is the part of the API that you'd be using as a
DataMapper
user, while a semipublic API is more for plugin authors). We
documented
and specced the *intended* behavior of each method, not necessarily
the actual behavior, and began working towards making those specs
pass.
As the spec coverage grew, we began to refactor some of the DM
internals
to make things more clear, but we tried not to get carried away with
this
unless it was necessary to make things work. In some cases, like with
relationships/associations, to match the intended behavior we had to
rewrite nearly all the code.
Even with us taking a conservative approach to rewriting internals,
there
were 2-3x more commits and changes between the 0.9 and 0.10 series
than
there were since the beginning of the DataMapper project and 0.9, so
this is a large update.
We also rewrote the Adapter API to make things easier for adapter
authors
to make full use of the DataMapper features. In the past many
adapters
only implemented partial behavior because the backends were limited in
what they could provide in terms of matching, sorting and limiting the
results. In those cases we're now providing helper methods to fill in
any holes in the storage engine capabilities.
What's left
-----------
While working on the 0.10 series we identified a number of areas of
improvement, but to avoid getting distracted we've added them to the
wiki: (Feedback welcomed)
http://wiki.github.com/datamapper/dm-core/roadmap
Many To Many associations are much more stable than in the 0.9 series.
One of the main reasons we decided to do this release is that we
noticed
we started spending more time telling people reporting bugs to
"try it with dm-core/next", and more often than not it did fix the
problem. Are we done with Many To Many associations? No -- there are
still a few known issues with edge cases -- but we're 95% of the way
there.
We still need to continue documenting more of the public and
semipublic
using YARD format. Also over the next few months we're going to work
on increasing the coverage of the specs even further.
What we need
------------
We're now at the point where we need some real-world testing outside
of
a few dedicated people who have been tracking edge. If you have a
spec
suite, then please upgrade DataMapper, run your specs and report any
issues you encounter. (Fix/ignore the deprecation warnings of course)
DataMapper is a pretty difficult project to fully spec due to it's
flexibility, and ability to use one of dozens of storage adapters. If
you do encounter a use case that we haven't covered, please submit a
ticket and we'll work on adding it to our spec suite.
Report any issues you find in IRC, on the mailing list, or in the
tracker:
IRC: #datamapper
Mailing List: http://groups.google.com/group/datamapper
Bug Tracker: http://datamapper.lighthouseapp.com/projects/20609-datamapper
Please search through the existing tickets prior to submitting, but
when in doubt please create a ticket. I would rather have to sort
through dupes or tickets that turn out to be resolved/invalid than
for a valid bug to go unreported.
Likewise if you're experiencing any problems with 0.9.x, please try
the RC1 and see if it resolves your problem. If it does, and you've
created a ticket for it, please add a comment to the ticket so we
can close the ticket.
--
Dan
(dkubb)
Brian Smith
Jun 19, 2009, 9:03:06 PM6/19/09
to DataMapper
Is there a list of api changes somewhere? I know with associations you
use :model => Class vs :class_name => "Class", any other prominent
gotchas?
On Jun 19, 1:36 pm, "Dan Kubb (dkubb)" <dan.k...@gmail.com> wrote:
> I am pleased to announce the release of DataMapper 0.10.0 Release
> Candidate 1.
>
> For the impatient, here are the command line instructions to install
> it:
>
> Install
> -------
>
> 1) Add gems.datamapper.org as a gem source:
>
> gem sources --addhttp://gems.datamapper.org
use :model => Class vs :class_name => "Class", any other prominent
gotchas?
On Jun 19, 1:36 pm, "Dan Kubb (dkubb)" <dan.k...@gmail.com> wrote:
> I am pleased to announce the release of DataMapper 0.10.0 Release
> Candidate 1.
>
> For the impatient, here are the command line instructions to install
> it:
>
> Install
> -------
>
> 1) Add gems.datamapper.org as a gem source:
>
Yehuda Katz
Jun 19, 2009, 9:21:08 PM6/19/09
to datam...@googlegroups.com
I believe that the API changes roughly amount to: "Don't believe anything you know from 0.9 -- 0.10 is quite different" ;)
-- Yehuda
Ted Han
Jun 19, 2009, 11:07:03 PM6/19/09
to datam...@googlegroups.com
:P /me jabs at Yehuda
The end user API changes aren't that dramatic and most the stuff that you need to do as an end user is depreciated and raises warnings. Getting Merb running w/ 0.10 is really not that complicated. I migrated my company's app without any changes to our app except changing some keywords here and there (:length for :size on string properties, and :model for :class_name in relationship declarations).
The internals have been rearranged fairly significantly. dkubb is working on a list of changes atm.
In general, the Adapter API changed, and Paul Sadukas (Rando) has a blog post about them here: http://www.theamazingrando.com/blog/?p=95
The code backing relationships, strategic eager loading, and collections has been re-written, but i'm not familiar enough w/ the old code (well except some of the relationships) to know exactly what's changed there.
dm-more 0.10 has been updated so that the specs all pass for 0.10. I'm personally a bit wary on that subject because the coverage is somewhat suspect, particularly when mixing and matching modules.
Hopefully a fuller accounting is coming down the road. But the point of 0.10 wasn't to totally ditch what 0.9 is supposed to be, it was an attempt to make it a bit more coherent, so far as i understand it.
-Ted
The end user API changes aren't that dramatic and most the stuff that you need to do as an end user is depreciated and raises warnings. Getting Merb running w/ 0.10 is really not that complicated. I migrated my company's app without any changes to our app except changing some keywords here and there (:length for :size on string properties, and :model for :class_name in relationship declarations).
The internals have been rearranged fairly significantly. dkubb is working on a list of changes atm.
In general, the Adapter API changed, and Paul Sadukas (Rando) has a blog post about them here: http://www.theamazingrando.com/blog/?p=95
The code backing relationships, strategic eager loading, and collections has been re-written, but i'm not familiar enough w/ the old code (well except some of the relationships) to know exactly what's changed there.
dm-more 0.10 has been updated so that the specs all pass for 0.10. I'm personally a bit wary on that subject because the coverage is somewhat suspect, particularly when mixing and matching modules.
Hopefully a fuller accounting is coming down the road. But the point of 0.10 wasn't to totally ditch what 0.9 is supposed to be, it was an attempt to make it a bit more coherent, so far as i understand it.
-Ted
Reply all
Reply to author
Forward
0 new messages