How to map this link table in cf-orm?

[Henry Ho]

A 1---* A_B *---1 B

Table A has aID (PK), Table B has bID (PK), table A_B has:

aID (PK, FK), bID (PK, FK), num

I tried

property name="As" fieldtype="many-to-one" cfc="A" fkcolumn="aID";
property name="Bs" fieldtype="many-to-one" cfc="B" fkcolumn="bID";
property name="num" type="numeric";

but CF keep asking me for an ID column... what can I do? The FK's
should be the PK's.

If there's no way to specify it in CFC, how to represent this link
table in hbmxml?

Thx

[Sumit Verma]

Any luck with this. Seems like it should be done using the
generator="foreign" but I'm not able to figure it out either.

[Andrew Scott]

This relates to a bug I raised, don't recall the Bug # at the moment. And
also blogged this problem on my website.

The problem is ColdFusion forces you to use an ID in your entity, if it
doesn't exist then it cracks it. This is a huge problem with legacy
databases as well, or any DB not designed by an ORM.

I tried

Thx

--

You received this message because you are subscribed to the Google Groups
"cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.
To unsubscribe from this group, send email to
cf-orm-dev+...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/cf-orm-dev?hl=en.

[Glen dunlop]

Andrew I read that blog you refer to, and I am amazed to be honest how a company could have released a product that has this many problems with it?

Was this ever discussed on the so called pre-release forums?

[Henry Ho]

I believe hbmxml can solve that, but I don't know enough hbmxml to
tackle it yet...

Henry

On Dec 28, 1:56 am, Glen dunlop <glen.dun...@gmail.com> wrote:
> Andrew I read that blog you refer to, and I am amazed to be honest how a
> company could have released a product that has this many problems with it?
>
> Was this ever discussed on the so called pre-release forums?
>

[Sumit Verma]

It works if you specify the relationship in the base tables and use linktable. The problem is when you want to create a cfc for link table to add additional fields...

[Henry Ho]

You mean many-to-many? It doesn't work in this case because I have an extra field 'num' in the link table.

Henry

[Sumit Verma]

Correct. I hope someone from Adobe team chimes in here with some solution :)

[Brian Kotek]

If you're trying to represent the relationship as a full entity, with it's own behavior and properties, then you can do this in code or in XML. The easiest thing to do would be to set up the linking object the same way you would any other entity, so something like this should work:

User:
component persistent="true" accessors="true"
{
    property name="id" fieldtype="id" ormtype="integer" generator="identity";
    property name="name" ormtype="string";
    property name="userRole" type="array" fieldtype="one-to-many" cfc="UserRole" fkcolumn="user_id" inversejoincolumn="user_id" cascade="all";
}

UserRole:
component displayname="role" persistent="true" accessors="true" table="user_role"
{
    property name="id" fieldtype="id" ormtype="integer" generator="identity";
    property name="user" fieldtype="many-to-one" cfc="User" cascade="all" fkcolumn="user_id" uniquekey="userRoleKey";
    property name="role" fieldtype="many-to-one" cfc="Role" cascade="all" fkcolumn="role_id" uniquekey="userRoleKey";

    property name="num" type="numeric";
}

Role:
component displayname="role" persistent="true" accessors="true"
{
    property name="id" fieldtype="id" ormtype="integer" generator="identity";
    property name="name" ormtype="string";
}

The generated user_role table will have its primary key, a unique key based on the combination of user_id/role_id, and two foreign keys mapped to the User and Role tables, respectively.

If you really, really want to use the two foreign keys as the primary key of the linking table, I believe you'll have to do this in the XML. But unless you have some crucial reason to do this, I wouldn't bother. The end result will virtually identical outside of the DDL.

[Henry Ho]

The reason I want to use the 2 FK's as PK's because then I can enforce that one User has only one type of UserRole.  It is hard to enforce that if the link table has its own unique key, unless I add an index on both property, which is essentially the same as using those 2 FKs as PKs.

Thx
Henry

[Brian Kotek]

Actually, considering how complex Hibernate is, the extent of what is going on under the hood, and the fact that this is a "1.0" release as far as the ORM features are concerned, it's pretty amazing that there are as few problems as there are.

I've tried to comment on things like this on Andrew's blog, but half the time he just deletes my comments if they contain the slightest rejection of whatever he's complaining about. So I've stopped bothering. The cases he's bringing up are not common and won't impact most people. Tables with no primary keys, even in legacy databases, are an edge case, not the norm.

That said, I've found Adobe to be very helpful and quick to respond to bugs or ERs when they are presented in a logical and respectful manner. So any issues he has with the CF engineers probably has more to do with his abusive attitude than anything else.

--

[Brian Kotek]

Setting up the unique key on the two columns should accomplish the same thing, yes?

[Henry Ho]

Yes, if you look at it from the Hibernate POV.  However, it doesn't make sense to set up the DB that way if you're look at if from the DB POV.  2 FK's as PK's would be the most logical choice in my opinion.

Thanks,
Henry

[Matt Quackenbush]

If you are a developer building an object-based application and you are utilizing Hibernate, why would you look at it from the DB POV?  That doesn't even make sense to me.  Not to mention the fact that from a DB POV, in my opinion, it makes things much simpler to set up a unique key on the two columns in the first place.  :-)

Translation: I'm with Brian on this one.

[Henry Ho]

:)

Matt, how is setting up unique key over two columns "much simpler"?  PK are indexed by default, if I have PK  and that unique key over two columns as index, wouldn't I end up with 2 indexes, and the PK index is not really used?

Using Hibernate shouldn't mean not looking at it from DB pov anymore though.  What if one day we don't wanna use Hibernate?  The DB should still make sense to the next guy who picked it up, right?  Data is still data.

Thx
Henry

On Mon, Dec 28, 2009 at 2:47 PM, Matt Quackenbush <quack...@gmail.com> wrote:

If you are a developer building an object-based application and you are utilizing Hibernate, why would you look at it from the DB POV?  That doesn't even make sense to me.  Not to mention the fact that from a DB POV, in my opinion, it makes things much simpler to set up a unique key on the two columns in the first place.  :-)

Translation: I'm with Brian on this one.

[Matt Quackenbush]

Consistency.  Consistency.  Consistency.

^ == simpler

When you consistently use a single incrementing/identity seed as a PK and declare your unique constraints as needed, then your database schema is much simpler to follow.  For you and for the next guy.  That said, if you consistently do the same thing in some other way, then the argument could be made that it is as simple.  Through all of the years that I've done this, I find it much simpler (for me) to consistently do the former.

I by no means am suggesting that you should disregard the database schema because you are using Hibernate.  For instance, I am completely uncomfortable with allowing Hibernate to declare/create my tables/schema for me.  I should have rephrased my initial comment.  The fact that you are using Hibernate is immaterial.  It does not make sense to me to think in objects and then analyze until you paralyze on your DB.

Bottom line is, in my opinion it is all about consistency.

[Henry Ho]

Thanks Matt and everyone else,

I don't mean to argue, I just want to learn.

Consistency?  If I use composite ID for every link table like the one in question, it is still consistence, no?

It surprises me that most of you prefer the extra ID column as PK.  I know that's the easier option in the hibernate / cf-orm context... but other than that...  Isn't 2 FK's as PK's the more efficient option?  One less index to update (speed), and on less column to store (space)?

Thx
Henry

[Brian Kotek]

In that case, try:

component displayname="role" persistent="true" accessors="true" table="usero_roleo"
{  
    property name="user" fieldtype="id,many-to-one" cfc="UserO" cascade="all" fkcolumn="user_id";
    property name="role" fieldtype="id,many-to-one" cfc="RoleO" cascade="all" fkcolumn="role_id";

    property name="num" type="numeric";
}

[Henry Ho]

WOW!  Brian you're the man!  That actually works!

I thought of that before, didn't know this actually works!  Is this documented?

Thank you very much!
Henry

[Sumit Verma]

Super! Couldn't be any easier :) Thanks Brian!

[Glen dunlop]

Brian,

What do you consider the norm then?

If one was to look at it this way, the majority of users would be upgrading their existing applications over to ColdFusion 9. This means that there will be a high majority of users who will be looking at trying to get their existing Database over to the new CF-ORM. With the problems that currently exist in the ORM, like forcing a user to have a unique ID field or not being able to map to primary keys and foreign keys correctly.

How can you sit there, and talk about what the norm is. Isn't that like Adobe sitting back and saying we will design it this way, because we expect that to be the use case, and then they find that this is not the case as they have continued to do.

Sorry but for me the Norm, is more people will be trying to map their current applications/databases into hibernate and have nothing but headaches.

This was apparently raised on the pre-release forums over 12 months ago from what I have been told, and Adobe have chosen to ignore it. So if Adobe are that helpful as you are claiming, then why has Adobe allowed this problem to exist?

[Andrew Scott]

Brian,

 

You know when you spread untruths it makes people think about it some, I only ever not allowed one of your comments. And the reason behind that was that it was full of XML crap, it can be considered slanderess if you sit back and tell people that I continue to ignore your comments on my blog when that is not in fact true.

 

As for Adobe being helpful, it was raised in the pre-release when I first started looking at the ORM in ColdFusion 9. Everytime I brought up the fact that it didn't work with legacy databases, everyone just point blank ignored it. Because I used grails as an example on how it should have been handled and implemented to give an example, not on how it should be done, but on how others had approached the problem.

 

not one person was interested to hear how grails had solved the problem, least of all Adobe so how is that being helpful?

 

I personally got sick of everyone jumping on my back everytime I mentione that grails could do it, so if they had found a solution then why couldn't Adobe do it in ColdFusion 9? So before you attack me in public, have a real hard look at those that attacked me when I was trying to improve the product, over 14 months ago!!

 

 

On Tue, Dec 29, 2009 at 9:32 AM, Brian Kotek <bria...@gmail.com> wrote:

[Glen dunlop]

Andrew I am going to have to agree with you, the norm would be that many are going to want to try mapping existing databases over, and their will be nothing more than problems. There are enough people out there bagging ColdFusion as it is now, and Adobe have all but given them more fuel to do so.

I have had nothing but trouble doing just that, your blogs have helped me some with understanding it as being an issue.

And I agree with you on why did Adobe not look into this as being a problem, if it was brought to their attention all those months ago. It sounds like those that harassed you when you did mention grails as an example, are more like the ones that really were not interested in improving the product in the first place.

Anyway this is not the place to debate this, the ORM in ColdFusion was certainly not ready for release and it is very clear that it was pushed out the door in a hurry because of the financial position of the company. That can't be denied, but when you do things like this it just reminds me of all the bad publicity that Microsoft got when they release Windows ME, and more recently Vista.

Adobe are going to have wear that, and I am sure that they will do a great job of addressing all the problems in the ORM in the update 1 for ColdFusion 9.

[Brian Kotek]

On Mon, Dec 28, 2009 at 8:23 PM, Andrew Scott <and...@andyscott.id.au> wrote:

Brian,

 

You know when you spread untruths it makes people think about it some, I only ever not allowed one of your comments. And the reason behind that was that it was full of XML crap, it can be considered slanderess if you sit back and tell people that I continue to ignore your comments on my blog when that is not in fact true.

Slanderess (sic)? Calling you out for nuking my comments isn't slanderous, Andrew. And it's happened more than once, but that's irrelevant. Just the fact that you only remember one, and admit to it, reveals volumes. I'm happy to leave it to anyone who has ever interacted with either of us over time to judge who's being honest.
 

 As for Adobe being helpful, it was raised in the pre-release when I first started looking at the ORM in ColdFusion 9. Everytime I brought up the fact that it didn't work with legacy databases, everyone just point blank ignored it. Because I used grails as an example on how it should have been handled and implemented to give an example, not on how it should be done, but on how others had approached the problem.
 

not one person was interested to hear how grails had solved the problem, least of all Adobe so how is that being helpful?

 

I personally got sick of everyone jumping on my back everytime I mentione that grails could do it, so if they had found a solution then why couldn't Adobe do it in ColdFusion 9? So before you attack me in public, have a real hard look at those that attacked me when I was trying to improve the product, over 14 months ago!!

 

Grails is a very nice piece of engineering, and Groovy is an amazing language (I've written a lot of code with it). I would agree that Adobe could probably learn more about it and apply some of the ideas to CF, and I would never say otherwise. But everything in Grails is not perfect, and just because you have an idea or see something elsewhere that you think should be used in CF doesn't mean that you're right.

[Andrew Scott]

Brian,

 

In all my time running my blog I have only ever once edited a comment due to sensitive information, and as I stated not approved one of yours thats right only one and as I still have a list of all none approved comments I would be more than happy to prove it, if I have too. But you know what Brian why should I, I do not have to sit back and listen to you make a claim, and then sit back and tell me that because I am more outspoken than you, that you are right either.

 

There was another time when one person made a comment on my blog, and asked me to pull it because he realised that it might have contained a bunch of XML from word or whatever he used. I did the same with yours because of the XML crap, and I will not debate you telling me otherwise in public. The length of that post and the amount of XML that I had to sift through and edit was not worth my time, and yes I could have emailed you and didn't so that makes me in the wrong for not letting you know. So shoot me, who cares really.

 

On the matter of grails, I have never said that I was right anytime I mentioned grails. But to point blank be shot down, and harrassed every time I did make that comparison says a lot for those people. Sure it could have been debated/discussed further but it never was, people just assumed what they thought there and then, and we'll leave it at that.

 

And yes I said it too, even to the Adobe engineers and the pre-release forums that Adobe could have and I will say it very clearly they could have learned a lot by a language that had already gone through it. However they chose to not do so, and they also chose to ignore backward compatability issues and the more work that is required to get around the problem.

 

Adobe have continued to sit back and make the claim of Rapid Application Development, and everytime it was suggested to improve areas that would help make it/keep that status they refused to acknowledge anything. Every E/R that was raised was SP5'ed, that tells me that they don't give rats ass about keeping the language RAD, it also tells me that on one hand when they claim that there user base wouldn't underastand something. They go an do the exact opposite with the other hand, that is not only confusing to begin with. But it makes Adobe look bad because they release something that they put a lot of thought into making one section easier for their core market as they put it, then they make it damn confusing because they didn't make it easier for those getting to know the new ORM making the language again evermore confusing.

 

If you read the blogs/tweets and all other information out there about how ColdFusion is bad, and why it is bad. It boils down to confusion within the lnaguage, and the testimont of some of the new features in ColdFusion 9 taking on an OO approach and the rest of it taking on a procedual approach makes it even more confusing leaving people thinking WTF!!

 

I never claimed to be alwasy right Brian, but I take huge accpetion to people just bagging me becuase they think they can. Or they think that because I chose to use a comparison with a language that Adobe could take notes from, that certain people would just go OMG here he goes again he just wont shut up about grails. But if those people actually stopped in the first place, and read further they would have seen more information that could have helped mould the language to something far better than what it is now.

 

Enough said...

 

 

[Brian Kotek]

On Mon, Dec 28, 2009 at 8:11 PM, Glen dunlop <glen....@gmail.com> wrote:

Brian,

What do you consider the norm then?

Glen, the "norm" is a database with tables that have a primary key, since that's how databases have been intended to work since the relational model was invented. Without primary keys (and corresponding foreign keys), most of the point of a relational database is lost. Put another way: with a database that has no primary keys, problems with an ORM are going to be the least of your worries.
 

If one was to look at it this way, the majority of users would be upgrading their existing applications over to ColdFusion 9. This means that there will be a high majority of users who will be looking at trying to get their existing Database over to the new CF-ORM. With the problems that currently exist in the ORM, like forcing a user to have a unique ID field or not being able to map to primary keys and foreign keys correctly.

I'm not sure exactly what you're referring to here. If you mean the object must define some kind of unique identifier, then yes, it does. It doesn't have to be a single field, it can be a composite key. But a unique identifier is required for reasons relating to how Hibernate determines object equality within the persistence context. (Ironically, a long blog comment about this is one of the comments Andrew deleted from his blog, or I would point you to it). What, exactly, is the problem of mapping primary keys to foreign keys? And what does this have to do with people using existing databases and having "nothing but headaches". Who are these people and what headaches are they having?
 

How can you sit there, and talk about what the norm is. Isn't that like Adobe sitting back and saying we will design it this way, because we expect that to be the use case, and then they find that this is not the case as they have continued to do.

Sorry but for me the Norm, is more people will be trying to map their current applications/databases into hibernate and have nothing but headaches.

This was apparently raised on the pre-release forums over 12 months ago from what I have been told, and Adobe have chosen to ignore it. So if Adobe are that helpful as you are claiming, then why has Adobe allowed this problem to exist?

I may be missing something here. What has Adobe ignored? What problem have they allowed to exist? The only "issue" that I've seen raised is the fact that you have to define an id/composite key and that the ORM doesn't create one for you automatically. Yes, it means you have to type one additional line of code in your CFC. Should it attempt to create an id for you if you don't define one? Sure, maybe it should. But it's definitely not some devastating problem. If you're referring to something else, by all means, point it out please.
 

[Glen dunlop]

Brian,

Yes, but you can't expect every single database out there to be designed correctly. Hell I have seen mapping tables with foreign keys and no primary key. The point is the same as Andrew pointed out in one of his blogs, Adobe should have adopted the acceptance that the ID would be created behind the scenes if one was not supplied.

The amount of going back and forth for a developer trying to map an older database that has been poorly designed, is not what I call being very RAD. Andrew made a very good point about this on his blog, and I agree Adobe should have looked at how other ORM languages had gotten around these type of problems and not sat back and forced the user to modify each entity that isn't conforming, until the developer had got every one correctly mapped.

After all ColdFusion is RAD right, so how is it so in this example!!

I am also very well aware of your next point that the database needs a unique identifier, I am also very well aware that it can be a composite key as well. The point that I was trying to get at has been answered in the above paragraphs.

So then you haven't tried to map a ColdFusion entity to a database that doesn't support foreign keys then I take it, or how about a database that has a foreign key in a certain format, Andrew has also blogged those issues as well.

I personally haven't had the time to blog or write much over the years, but after what I have played around with in ColdFusion 9 I have seen nothing but problems.

One major issue was under certain circumstance with a global event handler. And an entity with a certain type of ID field the record actually gets saved twice, throwing a ColdFusion error when doing so. Yet you switch that ID field to something normal like an integer and it works perfectly.

Or how about when you are designing a Database, and you are using the dropcreate option in the settings? And the expected fields are not what is in the Entity, for example when you have a date or timestamp then length of the field is 19, and yet if you decide to change that to a string instead then why is the string not 255 as its default? But instead 19, which is the length of the timestamp field? That tells me that there was not enough testing of the product in the first place either.

I could go on and on, but I think this issue is way of track here.

And just a side note, you might have a hatred for Andrew but that doesn't give you the right to attack him like you have done in these threads either. His point about not approving one of your comments was a very valid reason, but for you to turn around and attack him and then claim that you the bigger person because you must be right by your peers shows more immaturity than you think.

[Brian Kotek]

 On the matter of grails, I have never said that I was right anytime I mentioned grails. But to point blank be shot down, and harrassed every time I did make that comparison says a lot for those people. Sure it could have been debated/discussed further but it never was, people just assumed what they thought there and then, and we'll leave it at that.

 

And yes I said it too, even to the Adobe engineers and the pre-release forums that Adobe could have and I will say it very clearly they could have learned a lot by a language that had already gone through it. However they chose to not do so, and they also chose to ignore backward compatability issues and the more work that is required to get around the problem.

 

Adobe have continued to sit back and make the claim of Rapid Application Development, and everytime it was suggested to improve areas that would help make it/keep that status they refused to acknowledge anything. Every E/R that was raised was SP5'ed, that tells me that they don't give rats ass about keeping the language RAD, it also tells me that on one hand when they claim that there user base wouldn't underastand something. They go an do the exact opposite with the other hand, that is not only confusing to begin with. But it makes Adobe look bad because they release something that they put a lot of thought into making one section easier for their core market as they put it, then they make it damn confusing because they didn't make it easier for those getting to know the new ORM making the language again evermore confusing.

 

If you read the blogs/tweets and all other information out there about how ColdFusion is bad, and why it is bad. It boils down to confusion within the lnaguage, and the testimont of some of the new features in ColdFusion 9 taking on an OO approach and the rest of it taking on a procedual approach makes it even more confusing leaving people thinking WTF!!

 

I never claimed to be alwasy right Brian, but I take huge accpetion to people just bagging me becuase they think they can. Or they think that because I chose to use a comparison with a language that Adobe could take notes from, that certain people would just go OMG here he goes again he just wont shut up about grails. But if those people actually stopped in the first place, and read further they would have seen more information that could have helped mould the language to something far better than what it is now.

 

There are plenty of things CF could do better. As I said, Groovy and Grails would be fine things to look at for inspiration. What I'm trying to tell you is that the issue isn't the fact that you're pointing at Grails, it's the way you do the pointing. So much of what you say is filled with "doesn't give a rats ass" and "doesn't care" and "does nothing" and "in their wisdom" and "ignored" and "they need to" and "huge lack of support" and on and on. Can it really be a surprise to you that any good intentions you might have are lost in translation? Sorry, but they are.

In any event, this has gone far outside of the scope of the original post. If anyone wants to continue this discussion, I suggest a new thread be created.

[Glen dunlop]

Brian,

Did you ever take the consideration that Andrew is right?

That Adobe hasn't really cared about their user base, or that in their wisdom they did approach it wrong!!

I am not sure how much Andrew has used it like that, but just because he has doesn't give you or anyone else out there the right to attack back either. And from what I am reading between you too, there is that history. Brain why can't you be the bigger person and speak properrly to someone as well. Your first post about how your peers would back you up is testimony that you are more intent on continuing the problem.

Brain you get more by being polite back than not being polite back to you know.

[Scott Stroz]

Seriously? You are going to try and compare Brian's attitude and
reactions to those of Andrew? And thing Andrew is 'being the better
man'? Really?

Its funny how abusive Andrew has been on this and other listservs and
when someone finally stands up to him, they become the 'bad guy'. Are
we in Bizarro World?

> --
>
> You received this message because you are subscribed to the Google Groups
> "cf-orm-dev" group.
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to
> cf-orm-dev+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/cf-orm-dev?hl=en.
>

--
Scott Stroz
---------------
The DOM is retarded.

http://xkcd.com/386/

[Glen dunlop]

Scott,

 

I also find it funny how Andrew defended himself, which he was well within his rights to do so. Brian came back with an attitude that was like I will hide behind the skirts of the community.

 

If you ask me what Brian did was fuel it further to begin with, if he is not man enough to fight his own battles when challenged then how does that make Brian the bigger man. I asked Brian if he was reading it, that to be the bigger man he should think more about what statement he was saying by his comments.

 

As far as Andrew goes, so he is out spoken and a passionate ColdFusion developer, does that give you and Brian the right to call him a liar in public. And then harrass him when he answers his critics?

 

Have a good think about that one Scott, put yourself in Andrews shoes fort a minute and if you found that someone was chatting about you telling lies, and then when you confronted that person with what could be the truth you are attacked even further.

[Scott Stroz]

On Wed, Dec 30, 2009 at 1:18 AM, Glen dunlop <glen....@gmail.com> wrote:
> Scott,
>
> I also find it funny how Andrew defended himself, which he was well within
> his rights to do so. Brian came back with an attitude that was like I will
> hide behind the skirts of the community.

I fail to see anything inappropriate with anything Brian said. Nor do
I think he is 'hiding behind the skirts of the community'.

>
> If you ask me what Brian did was fuel it further to begin with, if he is not
> man enough to fight his own battles when challenged then how does that make
> Brian the bigger man. I asked Brian if he was reading it, that to be the
> bigger man he should think more about what statement he was saying by his
> comments.

'fueled it further to begin with' - if he fueled it further, how can
it be the beginning? I fail to see how he did not 'fight his own
battle'. He signed the email, we all know it came form him. Nor has he
denied the message came from him.

>
> As far as Andrew goes, so he is out spoken and a passionate ColdFusion
> developer, does that give you and Brian the right to call him a liar in
> public. And then harrass him when he answers his critics?

You call him 'outspoken' I would use other words to describe him, none
of which are appropriate for mixed company. From the attitude he has
displayed on this and other lists, there are a lot of people who would
agree with me. Though, I am sure you will accuse me of 'hiding behind
the skirt of other people' for that.

>
> Have a good think about that one Scott, put yourself in Andrews shoes fort a
> minute and if you found that someone was chatting about you telling lies,
> and then when you confronted that person with what could be the truth you
> are attacked even further.

I do not think Andrew was being attacked at all. Andrew is far from
being the innocent victim you are making him out to be. Honestly, if
Andrew is really incensed by what Brian said, maybe he should put
himself in the shoes of every person he has ever belittled on every
mailing list he has been a part of. That might help with some
perspective on his end.

[Peter Bell]

On Dec 30, 2009, at 8:31 AM, Scott Stroz wrote:

>> As far as Andrew goes, so he is out spoken and a passionate ColdFusion
>> developer, does that give you and Brian the right to call him a liar in
>> public. And then harrass him when he answers his critics?
>
> You call him 'outspoken' I would use other words to describe him, none
> of which are appropriate for mixed company. From the attitude he has
> displayed on this and other lists, there are a lot of people who would
> agree with me. Though, I am sure you will accuse me of 'hiding behind
> the skirt of other people' for that.

Ye kin hide behent mae kilt ony time Scott :-)

Peter

[Victoria Ryder]

Is this a community support list or Fight Club?  I joined mere days ago and am regretting it.  What silliness.

[Bob Silverberg]

I've been blissfully ignorant of this thread as I've been offline for
the past few days, but I think Vicky's point is valid.

This list is meant to be a resource for people to discuss questions
about and techniques with CF's Hibernate integration, which has not
been the focus of this thread for several messages.

To everyone involved, let's please let this thread die now.

Thanks,
Bob

On Wednesday, December 30, 2009, Victoria Ryder <vic...@gmail.com> wrote:
> Is this a community support list or Fight Club?  I joined mere days ago and am regretting it.  What silliness.

--
Bob Silverberg
www.silverwareconsulting.com

[Scott Stroz]

Bob,

You are totally correct. And I apologize to everyone for continuing
the spiraling of this thread the last few days.

> --
>
> You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to cf-orm-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.
>
>
>

--

[Brian Kotek]

I answered the OP and Henry has the information he needs, and have been silent on the subject since then. I'll only say to Glen that he has no idea what he is talking about, and his insults are really starting to wear on me. Glen, the next time you want to insult me over something you don't understand, email me directly. This list isn't the place for me to enlighten you about something that you have no knowledge of and that has been going on for years and involves a lot of people.

I appreciate what Scott is trying to do, but as I stated many messages ago, this thread is pointless. Let this die and let's move on.

Thanks,

Brian

[namtax]

Hi Brian

I have used this code to successfully use a link table, however I have
tried to adapt it to add a primary key to the link table but everytime
i do I get the DDL Export Error, am wondering how to adapt the code
for the link table to allow an autogenerated primary key

Many thanks

On Dec 28 2009, 11:16 pm, Brian Kotek <brian...@gmail.com> wrote:
> In that case, try:
>
> component displayname="role" persistent="true" accessors="true"
> table="usero_roleo"
> {
>     property name="user" fieldtype="id,many-to-one" cfc="UserO"
> cascade="all" fkcolumn="user_id";
>     property name="role" fieldtype="id,many-to-one" cfc="RoleO"
> cascade="all" fkcolumn="role_id";
>     property name="num" type="numeric";
>
> }
> On Mon, Dec 28, 2009 at 5:38 PM, Henry Ho <henryho...@gmail.com> wrote:
> > Yes, if you look at it from the Hibernate POV.  However, it doesn't make
> > sense to set up the DB that way if you're look at if from the DB POV.  2
> > FK's as PK's would be the most logical choice in my opinion.
>
> > Thanks,
> > Henry
>

> > On Mon, Dec 28, 2009 at 2:34 PM, Brian Kotek <brian...@gmail.com> wrote:
>
> >> Setting up the unique key on the two columns should accomplish the same
> >> thing, yes?
>

> >> On Mon, Dec 28, 2009 at 5:28 PM, Henry Ho <henryho...@gmail.com> wrote:
>
> >>> The reason I want to use the 2 FK's as PK's because then I can enforce
> >>> that one User has only one type of UserRole.  It is hard to enforce that if
> >>> the link table has its own unique key, unless I add an index on both
> >>> property, which is essentially the same as using those 2 FKs as PKs.
>
> >>> Thx
> >>> Henry
>
> >>>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "cf-orm-dev" group.
> >> To post to this group, send email to cf-or...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> cf-orm-dev+...@googlegroups.com<cf-orm-dev%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/cf-orm-dev?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "cf-orm-dev" group.
> > To post to this group, send email to cf-or...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cf-orm-dev+...@googlegroups.com<cf-orm-dev%2Bunsu...@googlegroups.com>

[Andrew Scott]

Link tables can't have primary keys in them.

[namtax]

Ok, so at the moment I have a table called "problem" and one called
"category", linked by the problemCategory table with columns
iProblemId, iCategoryId...the primarykeys from the two other tables
respectively...

When updating a problem (eg. problem with iProblemId =2), that may
have many categories, I need to delete all entries in the linktable
"problemCategory" where iProblemId = 2, so I can then add the new
categories for that problem afrresh

I presume there needs to be a primary key in the problemCategory table
for me to delete any entries?

Thanks

[Jon Messer]

It's perfectly fine to have a primary key in a link table, it could either be a composite key of the 2 foreign keys or a surrogate key. But you wouldn't be able to have hibernate create the constraint for you unless you specified creation DDL in a mapping file.

However you don't need to define a PK in order to do what you are asking. You could just build an array (or struct as the case may be) of the new categories that you want, then call 

problem.setCategories(newArray) 

That will replace, the existing collection, by deleting the link records and inserting new ones.

Hope that helps...

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+...@googlegroups.com.

[namtax]

Hi john, yes i thought you could have a primary key in a link table..

I appreciate the help, will give it a go at work tomorrow and let you
know how it goes

Many thanks

> > cf-orm-dev+...@googlegroups.com<cf-orm-dev%2Bunsubscribe@googlegrou ps.com>