OneToOne relationship? (was Re: Retrieving an object based upon a composed relationship) - transfer-dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion OneToOne relationship? (was Re: Retrieving an object based upon a composed relationship)
Received-SPF: pass (google.com: domain of armchairde...@gmail.com designates 209.85.217.19 as permitted sender) client-ip=209.85.217.19;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:content-type:message-id
         :content-transfer-encoding:from:subject:date:to:x-mailer;
        b=Cnqef6l/dx02ehW/hUAZSYxRRLC0qJtnXkFkxRjtbcYEXPtNu1utn4Gp1Yyx3P4381
         OyiI5I4jSxep/3XwQ5P+EZhHjntIloEOJnlMNfxN9s5MrnWKndY9RFk0A/Gqflacj7j7
         WaPHvE57o5AGZOkfxpdxChs8/Ls2i+UyZzPBc=
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To: <8c65a88f0809020624v282ee2a3ydd50005cffc1b...@mail.gmail.com>
References: <84eb8a50809020515j64c3cd34ye8c5b9bb68813...@mail.gmail.com> <8c65a88f0809020624v282ee2a3ydd50005cffc1b...@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <20B323D7-4ABB-40EB-8848-666B8F42D...@gmail.com>
Content-Transfer-Encoding: 7bit
From: Jared Rypka-Hauer <armchairde...@gmail.com>
Subject: Re: [transfer-dev] Re: OneToOne relationship? (was Re: Retrieving an object based upon a composed relationship)
Date: Tue, 2 Sep 2008 08:33:46 -0500
To: transfer-dev@googlegroups.com

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  
DB design... if you have a one2one join, you should consider putting  
the data together in the same table. Since supporting questionable DB  
design isn't within Transfer's charter, it's a question of Mark's  
time being spent on supporting something that shouldn't really be  
necessary in the first place or working on any of the bajillions of  
other enhancements or bug fixes that are essential.

Meanwhile, by means of a one2many on the 1:1 tables, you can achieve  
what's essentially the same behavior (or at least similar) insofar as  
getters and setters are concerned. Since a one2one is the same as a  
one2many with the one minor difference that the joining table will  
only ever have one related row, there's no particular reason not to  
go ahead and use it. If you want to enforce the 1:1 nature of the  
tables, just create a decorator, override the generated setFoo()  
method to indicate your preferred behavior (throw error? overwrite  
original record? backup record then overwrite?).

I guess that brings up yet another point against this... what's the  
desired behavior when calling Bar.setFoo(Foo) on a 1:1 relationship?  
There's too many viable options in this case to have consistent and  
acceptable results. So we're back to using a one2many and overriding  
the generated methods in a decorator. If you have a one2one  
relationship, this is not just your only option but quite possibly  
the most elegant option available.

J


On Sep 2, 2008, at 8:24 AM, Bob Silverberg wrote:

>
> This has been discussed a few times before.  I know that I have asked
> this question at least twice, and the response has always been that
> one2one represents an edge case, and that the resources required to
> implement it could be used elsewhere to greater benefit.  At least
> that was the way I interpreted the response.
>
> I didn't agree with this, not entirely anyway, as I have used one2one
> on numerous occasions, but that was just my opinion.  If anyone else
> sees this as a valuable enhancement please speak up, and maybe it can
> get added as an enhancement request.
>
> Cheers,
> Bob
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
