On Tue, Sep 2, 2008 at 10:52 AM, Bob Silverberg <bob.silverb...@gmail.com>wrote:

Yes, this is exactly where I ran into the use of this as well. There are
definitely situations where you know you want only a one to one relationship
between two tables due to limitations in translating an object model into a
relational schema. There are also cases where you have extended information
that you don't necessarily always need, but that nonetheless exist in a one
to one relationship with some other entity.

On Tue, Sep 2, 2008 at 9:33 AM, Jared Rypka-Hauer
<armchairde...@gmail.com>wrote:

I don't think it should be Transfer's job to determine what is or is not
"questionable" database design. The whole point of an ORM is to automate the
mapping an object model into relational data. As soon as we start making
decisions based on database design, we're back to the old (and,
unfortunately, valid) argument that most ORMs force your database structure
onto your object model, instead of the other way around. What might be
considered a "bad" relational model for a traditional OLTP database goes out
the window pretty quickly when you start talking about ORMs. We aren't
building an OLTP schema, we're building an object persistence schema, and
the two can very easily end up in conflict.

The problem I have with it is that it results in a domain model that is
misleading. Say I have a Product table. It contains base information common
to all Products, such as price. However, I may sell Books. I may have a Book
table, with a ton of extended information about books like author, number of
pages, ISBN number, etc. Surely it would be less than ideal to add all of
those columns to the Product table when a huge number of the rows won't even
use them. But clearly there is indeed a one to one relationship between Book
and Product.

Now, say I want to generate a Value Object for my Book. Ideally, Transfer
would support multiple-table inheritance mappings, but we don't have that
yet (though it is on the feature list). In lieu of that, the optimal way
Transfer would let me structure it would be that Book has a property which
is a Product. But looking at the metadata, I have no way to determine this.
Instead, I have to use a one to many, in which case Book has an ARRAY of
Products, despite the fact that there is no multiplicity.

It also results in an API that is unnecessarily difficult to use. Within
Book, if I want to get the Product, I have to do something like:

product = getProductArray()
product = product[1]

instead of simply getProduct(). Not only is it more work, but it is
misleading code, as well as relying on the "magic number" 1, and magic
numbers make my skin crawl. :-)

If you want to enforce the 1:1 nature of the

Since I generate a great deal of my code, having to manually write a
Decorator to address this makes my life more difficult. The answer to many
previous feature requests could have been "write a decorator method to
handle it", but that doesn't mean I can't ask for an easier way. ;-)

I don't follow. If I have a Product and a Book, and I call
book.setProduct(product), what exactly is the problem? How is this any
different than the way one calls setParentFoo() or addFoo()?

Obviously I've worked around this issue, but I would argue that it was
enough of a pain (especially once you have multiple subtype/supertype
relationships in your model) to warrant some consideration. Mark can (and
I'm sure will hehe) jump in, but on the surface it seems that unless the
inheritance mapping feature is coming in the forseeable future, something
like this might be a valid interim solution.