same column name in parent/child table

[Sana]

Hi Isaac

If we have two column with same name with parent and child table. so
which one will have preference.

item.cfc
ItemID = 1324
ContentName = 'Some test'
ContentDate = ''

<cfcomponent extends="datafaucet.system.activerecord">
<cfset setTable("tItem") />
</cfcomponent>

And content.cfc
CID = 563
ItemID = 1324
ConentDetail = 'some detail'
ContentUniqueString = 'FA9E2857-30BD-B5E8-D755CB8A867B3F75'
ContentURL = '/FA9E2857-30BD-B5E8-D755CB8A867B3F75'
ContentDate = '01-01-2008'

<cfcomponent extends="item">
<cfset addTable(table = "tContent",
column="ItemID", references="ItemID") />
</cfcomponent>

ContentDate will be always show empty because this column is in parent
table.
Is there any way to change child table column name.

[Isaac Dealey]

> Hi Isaac
>
> If we have two column with same name with parent and child table. so
> which one will have preference.

That's a good question...

<snip>

> ContentDate will be always show empty because this column is in parent
> table. Is there any way to change child table column name.

Forgive me if I sound rude. I've been trying to decide how to offer an
answer without seeming confrontational.

Is there a particular use case in which you feel there's an advantage to
having the same column name in both tables?

I'm having a difficult time understanding the reason why these two
tables would have a column with the same name.

In the example of content for a CMS, say you're wanting all the content
to have a record in a common table and then individual types of content
will have their own table, so for example "news articles" will have
different properties than a "page".

If you've got a date column in the common table, that's going to
represent a date that all content has, so it should only exist in the
common table, i.e. "common.ContentEnteredDate", because all content will
have a date on which it was entered, irrespective of the type of content.
News articles and pages will both have it.

If you then have any kind of date that will only exist for news articles,
then that would appear in the news articles table, i.e.
"article.PublicationDate". This wouldn't make sense in the common table
and shouldn't be placed there because not all content will have a
publication date.

My gut feeling is that if you have a situation where the same column
appears in both tables, such as "ContentDate", that each of those
columns are likely to represent something different and that there's a
good chance the column names could be improved by making them more
specific. It might be that you're using "contentdate" in the common
table to represent the date the content was entered and then also using
"contentdate" in the news table to represent the publication date. Which
I think is likely to cause confusion with or without an ORM and it's
likely a better solution to rename those columns to make them more
specific like ContentEnteredDate and PublicationDate.

There's not currently a built-in method of creating wholesale column
aliases in the ActiveRecord object. So there's no way to simply say "the
contentdate column feeds the publicationdate property". That's actually
something I want to avoid because I feel those kinds of changes lead to
confusion and problems in development.

--
[ ike ] founder - DataFaucet ORM

phone: 781.769.0723

http://www.datafaucet.com

[Sana]

HI Isaac,
much appreciated for your detail response. For sure column name should
be unique but I am assessing a legacy App to convert with datafaucet.
All I was looking to have less work for myself.

I hope your answer will help for other users of datafaucet.

Again thanks for great co-operation.

Thanks

[Isaac Dealey]

> HI Isaac,
> much appreciated for your detail response. For sure column name should
> be unique but I am assessing a legacy App to convert with datafaucet.
> All I was looking to have less work for myself.
>
> I hope your answer will help for other users of datafaucet.
>
> Again thanks for great co-operation.

Oh okay... yeah, legacy apps suck. :-/

I honestly wish I felt like there were some way to make legacy apps
easier to work with... the problem with trying to do things that resolve
those issues is that the solution frequently lends itself to bleeding
into new development and causing confusion -- essentially, dragging the
problems of legacy applications forward into new development.

One thing that I've done in the past, and it may not work very well in
your situation, is to create an updatable view using instead-of triggers
for insert and update statements. This places the work of mapping those
columns in the database and makes it transparent to the ORM. There is of
course some extra overhead on the database side, which may or may not be
a problem... and it also has to be a database that supports updatable
views and in an environment where you're allowed to create views and
triggers.

I've worked in a number of environments, particularly corporate
environments likely to have these kinds of legacy systems, where one or
several of those conditions prevented me from using the updatable view.
I know a lot of corporations have fairly stringent access rights on
their databases, so it's often not possible to create one because the
Oracle DBAs in the other department won't allow it.

If you need columns that will be read-only (non-updating columns), it
should be relatively easy to override the method that generates the
read() query. It should be relatively easy to do if you examine the
content of the "executeRead" method.