February Is The Month Of Love: Give DataMapper Some!

[Sam Smoot]

So you don't get anywhere without big goals right? I mean, I would
have never started DataMapper without thinking we could pull off
something great. :-)

So here's the idea: DataMapper goes 1.0 by MWRC.

This means:

* We need at least one of the three styles of ClassicMigrations to
make it into trunk, we need to document it, we need a page on the
website, and it needs to be relatively feature complete.

* We need full Transaction support. I think Paul has taken the lead on
some of this, getting in a patch to DataObjects to make it happen. We
just need to get it the rest of the way... I'm thinking
Adapter#connection could call #create_connection when not in a
transaction, and return the current transaction when in one.

* DataObjects needs some love. Lets get those paths fixed! Let's get a
Windows binary! Lets get rid of SWIG! Let's get rid of the mysql-dev
package dependency! I know there's some experienced C guys out there,
let's make it happen!

* We need to swap in the new Query class. It'd be nice to have the OR
condition support that's been chatted up lately...

* We need to use the Property instances generated by
DM::Persistence::property, and not access the Table#columns directly
anymore. This will lead to letting us...

* Make one Table instance for each table in the database. Right now
you have an instance for each mapped class, along with an instance
that gets returned when you look it up by String. This is extra memory
overhead (granted, not a ton, but still), slower performance (ditto),
but most of all, it just makes things more complex and makes it harder
to conceptualize the *runtime* internals of DM.

* Associations! They suck :p I mean, the code just isn't well factored
or consistent right now, and I've killed their performance. Let's
clean 'em up and get 'em back up to speed. Make the internals of
TypedSet use an Array, not a SortedSet, it's too slow. :-(

* Optimistic Locking: I'm against automatic locking, but value locking
with property :lock => true, and row-locking with
property :row_version, :string are definitely needed.

* Sharon Rosner and Ezra Zygmuntowicz were nice enough to join forces
on the Assistance gem (http://rubyforge.org/projects/assistance),
let's beef it up! Get it used in DM, get rid of our own Inflector,
etc.

There's lots of great work that has gone into DM so far, but it's
leaking a bit at the seams right now. Let's patch it up, iron the bugs
out and get it out the door! I'm going to be spending every minute I
can on this in the coming month, but I need your help!

w00t!

[Luke Sutton]

Sam, this is jut the kind of overview we need!

Using assistance looks interesting. I notice that it has some things
in it that look redundant in DM. For example the validations. Is there
any plan to handle that, or just ignore it?

At least replacing the current inflector code with that in assistance
seems like a good start.

I'll have a go at that -- assuming I can stop being flaky as all get
go.

--
Luke

[psada...@gmail.com]

Transactions: It's pretty dependent on connection pooling, which, and
I agree, Sam is moving into DataObjects. I started on pg, but didn't
get very far because of time constraints. If we could finish moving
pooling, then I can whip up patches for transactions in DO & DM pretty
quick. Then once thats done, get Migrations to use them, and make a
patch for that.

As for Assistance, it seems like it has a lot of overlap with Facets.
(Time calculations, Inflectors...) And isn't validatable already its
own gem? Where does this fit in?

Paul

[Luke Sutton]

That's a good point. Should we be considering Facets instead? Or
perhaps making Assistance into Facets-lite?

On Feb 8, 5:18 pm, "psadaus...@gmail.com" <psadaus...@gmail.com>
wrote:

[Ezra Zygmuntowicz]

We aren't using the assistence gem in merb. We are using the
Inflector from facets 'english' project though, it is 3 times faster
then the inflector from rails.

-Ezra

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com

[thanatos]

ReinH and I are moving on OR conditions and beefing up conditions
parsing in general, moving it out of Query. At that point, let's swap
in Query. I'll have to chat with ReinH to get a timeline.

[Jeff Casimir]

DMers,

I'm new to DM and not very experienced with the details of implementing libraries and such - but I'd like to help out.

I know the most interesting challenges are the technological, but I'm a pretty good writer and would be happy to pitch in a little with documentation/tutorials.  Is there a big to-do list somewhere?  If not, can we start one?

It would be helpful to...

- Determine some code documentation standards (if there aren't already - maybe look at what Merb's doing and "standardize"?)

- Set goals/requirements for documentation of contributed code

- Begin collecting all the existing resources that are scattered around (blog articles, etc)

I think the Rails wiki was HUGE for the cultivation of the early community.  Could we integrate one into datamapper.org?  I would be happy to "dogfood" a wiki engine in merb and datamapper if people were interested.

There is obviously a lot of buzz in the "alternatives to traditional Rails" sphere.  We need to make sure that we can capture lasting interest for the project to be successful.

- Jeff

[Mayo Jordanov]

I wouldn't mind looking at using Property instances rather than
Table.columns, partially because of some extensions I want to write
for the PostgresqlAdapter that I can't do now without modifying the
AbstractAdapter/DataObjectAdapter.

I might need a mentor being relatively new to DM and all, but I've
done fair amount of digging at the code.

mayo

[David Leal]

Still working on custom types here, but I've been busy lately so it's
taking more than I would like. :(

David

[ngo...@googlemail.com]

IMNSHO, one of the most important things that DataMapper needs is API
documentation. As it is now, the API doc that's available online is
completely useless.

[Adam French]

I'm leaning towards adopting the Merb API documentation style with the
documentation I'll be committing over the next few days.

http://yehudakatz.com/2008/01/14/merbnext/

Sound good?
===
~Adam

[je...@casimircreative.com]

Aligning with Merb's standards would be prudent. As I mentioned in
Yehuda's article, I'd like to see additional sections that link to
tests that directly use the method and a way to have examples usage
that can be extracted and tested as part of the build. Maybe we
implement the test links, then establish a special subset of tests
whose primary purpose is to demonstrate functionality, not just prove
it. Maybe tests could include "tags" to mark their purpose
(funtionality, documentation, others?) and/or references to the
methods/concepts they address.

Am I making sense or is this just dumb?

[Adam French]

With all of the specs inside the spec/ folder, perhaps we should just
somehow link to specs which demonstrate the usage of whatever methods
we're documenting at the time.

I don't think there's an rdoc-like thing for specs yet.....that would
rock.
===
~Adam

[Michael Irwin]

Sorta off-topic, but has anyone else noticed all methods in the DM
rdoc are being defined twice? For example, these are the first two
links in the "Methods" frame of the DM rdoc for me (the "+" method):

datamapper-0.3.0/rdoc/classes/DataMapper/Support/TypedSet.html#M000803

datamapper-0.3.0/rdoc/classes/DataMapper/Support/TypedSet.html#M000815

I've tried removing the cached gem, deleting the installed DM rdoc
directory, and making sure DM is only installed once, but every time I
install DM, this issue reappears.