From: "Brian Kotek" <brian...@gmail.com>
Date: Tue, 2 Sep 2008 12:16:39 -0400
Local: Tues, Sep 2 2008 12:16 pm
Subject: Re: [transfer-dev] Re: OneToOne relationship? (was Re: Retrieving an object based upon a composed relationship)
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
> I have to disagree with this. One2one is a useful relationship when
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
I don't think it should be Transfer's job to determine what is or is not
> I think there's more to it than just the diversion of resources...
> one2one is considered an edge case because it's not particularly good
"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
> Meanwhile, by means of a one2many on the 1:1 tables, you can achieve
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
Now, say I want to generate a Value Object for my Book. Ideally, Transfer
It also results in an API that is unnecessarily difficult to use. Within
product = getProductArray()
instead of simply getProduct(). Not only is it more work, but it is
If you want to enforce the 1:1 nature of the
> tables, just create a decorator, override the generated setFoo()Since I generate a great deal of my code, having to manually write a
> method to indicate your preferred behavior (throw error? overwrite
> original record? backup record then overwrite?).
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
> I guess that brings up yet another point against this... what's the
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
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.