Choosing an ORM

Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

I'm totally biased, so I won't give you an opinion one over the other - however, to note, if you are using stored procs, then you won't be able to use Transfer. Simply put - it writes all that SQL for you, so you don't have to... so why would you need the integration? Mark ----- Excess quoted text cut - see Original Post for more -----

Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

No worries, Yeah, if you are working on large imports/data management then I would look at using SP's/DTS/SSIS but I would no doubt trigger them asynchronous as well and I would probably not use the web to control the jobs outcome (as in a job completion notification) as long running requests like that as a bitch to handle and are wasted resources unless you have a dedicated instance doing all that legwork etc. You want to encrypt all of your data in and out of your app? Location: London. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Yeah, Basically just a standard encrypt()/decrypt() on the data as it passes in and out of the database. But rather than hard coding the key into a CFM file and storing it in Application.EncKey I was thinking about encapsulating it in its own object, makes life simple as I can have it injected as a constructor into my DAO's for when the public/pull data from the database. Location: West Sussex. Thanks Neil, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:43 To: CF-Talk Subject: RE: Choosing an ORM No worries, Yeah, if you are working on large imports/data management then I would look at using SP's/DTS/SSIS but I would no doubt trigger them asynchronous as well and I would probably not use the web to control the jobs outcome (as in a job completion notification) as long running requests like that as a bitch to handle and are wasted resources unless you have a dedicated instance doing all that legwork etc. You want to encrypt all of your data in and out of your app? Location: London. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Couldn't you just use SSL or are you storing the data encrypted in a column? "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com Yeah, Basically just a standard encrypt()/decrypt() on the data as it passes in and out of the database. But rather than hard coding the key into a CFM file and storing it in Application.EncKey I was thinking about encapsulating it in its own object, makes life simple as I can have it injected as a constructor into my DAO's for when the public/pull data from the database. Location: West Sussex. Thanks Neil, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:43 To: CF-Talk Subject: RE: Choosing an ORM No worries, Yeah, if you are working on large imports/data management then I would look at using SP's/DTS/SSIS but I would no doubt trigger them asynchronous as well and I would probably not use the web to control the jobs outcome (as in a job completion notification) as long running requests like that as a bitch to handle and are wasted resources unless you have a dedicated instance doing all that legwork etc. You want to encrypt all of your data in and out of your app? Location: London. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

It's for encrypting data in the Column when its stored in the database. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 11:00 To: CF-Talk Subject: Re: Choosing an ORM Couldn't you just use SSL or are you storing the data encrypted in a column? "This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540.  It contains information which is confidential and may also be privileged.  It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful.  If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910.  The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com Yeah, Basically just a standard encrypt()/decrypt() on the data as it passes in and out of the database. But rather than hard coding the key into a CFM file and storing it in Application.EncKey I was thinking about encapsulating it in its own object, makes life simple as I can have it injected as a constructor into my DAO's for when the public/pull data from the database. Location: West Sussex. Thanks Neil, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:43 To: CF-Talk Subject: RE: Choosing an ORM No worries, Yeah, if you are working on large imports/data management then I would look at using SP's/DTS/SSIS but I would no doubt trigger them asynchronous as well and I would probably not use the web to control the jobs outcome (as in a job completion notification) as long running requests like that as a bitch to handle and are wasted resources unless you have a dedicated instance doing all that legwork etc. You want to encrypt all of your data in and out of your app? Location: London. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

In fact, re-reading the docs re: SP's I am not even sure you can cache them... [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 10:26 To: CF-Talk Subject: RE: Choosing an ORM Cheers Neil, Yeah I agree there are some issues with stored procs, but things like caching are something I don't really have to deal with in this application, the site isn't public facing and the majority of the data within the app needs to be 'real-time' so we tend not to cache. However, that IS an exciting feature in Scorpio, can't wait to upgrade :-) I know that debugging and things can be a bit of a hassle, but generally all the queries are written in CF as a proof of concept first, once we have a working model then we'll migrate them over to stored procs for the production version. Also a large amount of our more complex queries are for data imports and moving large amount of data around, so being able to have SQL server do all the donkey work is a god send. I've not done much testing on performance myself but I like the concept of the separation using them gives and if we get boosted performance as a result then that's just a fringe benefit. The other benefit of the stored proc method is portability of the database, There is a possibility that in the future we'll have to bolt on some more JAVA based apps to the server and if we can have them share the same query set without having to rewrite it all, then that'd be nice too. Any ideas on that encryption stuff? I'm trying to figure out the best way to implement it, I'm almost 100% convinced giving it a class makes sense, especially if working with a factory, I can define my key in the XML and have it inject an instance into all my DAO's with the minimum of hassle. Thanks again mate, where abouts in the world are you sending from? By the way you spell 'arse' I'm guessing you're a fellow UK resident. Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 10:00 To: CF-Talk Subject: RE: Choosing an ORM From experience, it can be a easy to choose SP's for their "speed", but I have found that cfquery can perform just as well, and even better in some cases.   Sure you get the multiple recordset ability with an SP but unless you are using CF8 you still cannot cache results - unless you roll your own mechanism which is an arse. They are also harder to debug but that is no doubt something you know and can live with! I would use them but I would think about using them sparingly and if you can to use an ORM - don't us them at all. [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:47 To: CF-Talk Subject: RE: Choosing an ORM Thanks Neil and Mark, I remember the whole 'active' records and really liked that concept, but to be honest I've gotten myself tied quite nicely into using stored procs recently and don't really want to move back, I'm quite happy. I've got a small CFC setup here that generates all my beans, DAO and Gateway for my simple objects so that will probably do the job and a ORM might not be necessary, I can probably survive without all that advance stuff for the moment. One thing I would like to quickly ask, whilst on the subject of data access, how do you guys deal with encryption in an OO environment? Do you just dump the key into your app scope? Or do you create an encryption class that stores it as a property, along with the other settings and place that as a singleton into your app scope? And how do you utilize that in your DAO? Inject it as a constructor? Thanks again for your input chaps, Rob [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: 04 June 2007 09:25 To: CF-Talk Subject: RE: Choosing an ORM Morning, From what I can see, it had a divorce in that it is not longer intrinsically tied into MG. With MG:U you have ORM Adaptors which means you can choose either Reactor or Transfer (or any other should they come about or exist). Stored Procs aren't going to really fit the ORM bill it really has to be direct object to table access from what I can see. What I have found with Reactor is that since it is an ActiveRecord process it has to be a 1:1 object mapping to a real physical table.  It is less flexible that Transfer. With Transfer you have a little bit more flexibility with decorators but it still lacks in some areas (and excels in others) - composite keys is one area but I know Mark is working on a fix for this so it can support them. HTH N [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 09:06 To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

> In fact, re-reading the docs re: SP's I am not even sure you can cache > them... You can in CF8 -- Tom Chiverton Helping to widespreadedly e-enable professional supply-chains on: http://thefalken.livejournal.com **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF.  A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged.  If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents.   If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com.

Yeah you can't cache in anything other than CF8, Rob > In fact, re-reading the docs re: SP's I am not even sure you can cache > them... You can in CF8 -- Tom Chiverton Helping to widespreadedly e-enable professional supply-chains on: http://thefalken.livejournal.com **************************************************** This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF.  A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged.  If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents.  If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com.

I'm not going to jump in to Reactor vs Transfer.  They're both great products.  I wish I could use them. (We have a mandate for stored procs. )   But if you're looking to handle stored procedures, may I make a plug for my product, Squidhead (http://squidhead.riaforge.org/). It doesn't have hooks for any of the other frameworks yet, but it does implement the DAO and Gateway for a MSSQL database using stored procedures. And while it doesn't have any hooks for the frameworks, there's nothing to stop it from working with modelglue, or fusebox. In addition to writing its own CRUD in stored procs, it also reads in and makes available your stored procedures as CFC methods. It can handle multiple queries proc call, etc.    Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Thanks Terrance, I've not seen Squidhead before, but if it's as good as it sounds then It would be perfect for me, anything to avoid writing DAO code ;-) I'll have a look at it this afternoon, but it sounds fantastic, Rob I'm not going to jump in to Reactor vs Transfer.  They're both great products.  I wish I could use them. (We have a mandate for stored procs. )   But if you're looking to handle stored procedures, may I make a plug for my product, Squidhead (http://squidhead.riaforge.org/). It doesn't have hooks for any of the other frameworks yet, but it does implement the DAO and Gateway for a MSSQL database using stored procedures. And while it doesn't have any hooks for the frameworks, there's nothing to stop it from working with modelglue, or fusebox. In addition to writing its own CRUD in stored procs, it also reads in and makes available your stored procedures as CFC methods. It can handle multiple queries proc call, etc.    Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: Monday, June 04, 2007 4:06 AM To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Can anyone recommend an ORM that works with MySql? ----- Excess quoted text cut - see Original Post for more -----

I'm fairly certain both Reactor and Transfer do so. Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu Can anyone recommend an ORM that works with MySql? ts/unsubscribe.cfm?user=22052.16742.4

Certainly does look nifty..be good to see what kind of performance his it has though... [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 14:40 To: CF-Talk Subject: RE: Choosing an ORM Thanks Terrance, I've not seen Squidhead before, but if it's as good as it sounds then It would be perfect for me, anything to avoid writing DAO code ;-) I'll have a look at it this afternoon, but it sounds fantastic, Rob I'm not going to jump in to Reactor vs Transfer.  They're both great products.  I wish I could use them. (We have a mandate for stored procs. )   But if you're looking to handle stored procedures, may I make a plug for my product, Squidhead (http://squidhead.riaforge.org/). It doesn't have hooks for any of the other frameworks yet, but it does implement the DAO and Gateway for a MSSQL database using stored procedures. And while it doesn't have any hooks for the frameworks, there's nothing to stop it from working with modelglue, or fusebox. In addition to writing its own CRUD in stored procs, it also reads in and makes available your stored procedures as CFC methods. It can handle multiple queries proc call, etc.    Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: Monday, June 04, 2007 4:06 AM To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Well.... When it generates the code it's not blazingly fast.  A simple application takes about 5 seconds on my laptop, a more complicated one takes anywhere from 20 seconds to a minute. (On server class hardware it is obviously much faster.)  But that's why it's a passive code generator, instead of an active one. However once the code is generated, it's executed pretty fast, assuming that the underlying table structures are properly indexed and whatnot.  Even an improperly indexed table will be okay, at least for awhile. I typically see either 0 or 16ms for individual calls.   Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu Certainly does look nifty..be good to see what kind of performance his it has though... [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 14:40 To: CF-Talk Subject: RE: Choosing an ORM Thanks Terrance, I've not seen Squidhead before, but if it's as good as it sounds then It would be perfect for me, anything to avoid writing DAO code ;-) I'll have a look at it this afternoon, but it sounds fantastic, Rob I'm not going to jump in to Reactor vs Transfer.  They're both great products.  I wish I could use them. (We have a mandate for stored procs. )   But if you're looking to handle stored procedures, may I make a plug for my product, Squidhead (http://squidhead.riaforge.org/). It doesn't have hooks for any of the other frameworks yet, but it does implement the DAO and Gateway for a MSSQL database using stored procedures. And while it doesn't have any hooks for the frameworks, there's nothing to stop it from working with modelglue, or fusebox. In addition to writing its own CRUD in stored procs, it also reads in and makes available your stored procedures as CFC methods. It can handle multiple queries proc call, etc.    Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: Monday, June 04, 2007 4:06 AM To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

Yeah, From what i've seen whilst reading the documentation it simply writes all the laborious code for you, there is nothing to stop you modifying all those DAO's, Gateways and Stored Procs to optimize them afterwards, it just gives you a nice working model to start with. Like Terrence says, provided your database is built properly in the first place then I'm sure it'll run very efficiently. It doesn?t look like the Reactor framework, its just a CFC generator by the look of things, I'll let you know how I get on with it. Thanks, Rob Well.... When it generates the code it's not blazingly fast.  A simple application takes about 5 seconds on my laptop, a more complicated one takes anywhere from 20 seconds to a minute. (On server class hardware it is obviously much faster.)  But that's why it's a passive code generator, instead of an active one. However once the code is generated, it's executed pretty fast, assuming that the underlying table structures are properly indexed and whatnot.  Even an improperly indexed table will be okay, at least for awhile. I typically see either 0 or 16ms for individual calls.   Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu [mailto:Neil.Robertson-Ravo@csd.reedexpo.com] Sent: Monday, June 04, 2007 10:08 AM To: CF-Talk Subject: RE: Choosing an ORM Certainly does look nifty..be good to see what kind of performance his it has though... [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: 04 June 2007 14:40 To: CF-Talk Subject: RE: Choosing an ORM Thanks Terrance, I've not seen Squidhead before, but if it's as good as it sounds then It would be perfect for me, anything to avoid writing DAO code ;-) I'll have a look at it this afternoon, but it sounds fantastic, Rob I'm not going to jump in to Reactor vs Transfer.  They're both great products.  I wish I could use them. (We have a mandate for stored procs. )   But if you're looking to handle stored procedures, may I make a plug for my product, Squidhead (http://squidhead.riaforge.org/). It doesn't have hooks for any of the other frameworks yet, but it does implement the DAO and Gateway for a MSSQL database using stored procedures. And while it doesn't have any hooks for the frameworks, there's nothing to stop it from working with modelglue, or fusebox. In addition to writing its own CRUD in stored procs, it also reads in and makes available your stored procedures as CFC methods. It can handle multiple queries proc call, etc.    Terrence Ryan Senior Systems Programmer Wharton Computing and Information Technology       E-mail:         tpryan@wharton.upenn.edu [mailto:robert.rawlins@thinkbluemedia.co.uk] Sent: Monday, June 04, 2007 4:06 AM To: CF-Talk Subject: Choosing an ORM Hello Guys, I've just started work on a large scale rebuild of my core business application, and to aid me the gruelling task I'm toying with implementing MG, ColdSpring and one of the ORM's. I've done some small work with these in the past but used Reactor. Now, I'm sure I've read somewhere that Reactor and MG got a divorce, and that MG would most likely end up sleeping with Transfer, is this the case? Another thing to take into consideration is that I had planned to take all my queries and move them into stored procs on my SQL Server as some of them were getting pretty fat and needed a helping hand to keep performance where I want it, will I still be able to do this when working with an ORM? What are your thoughts on this stuff? What's hot? And what's not? Look forward to hearing from you guys, Rob

I think most of the popular ORM's (Reactor and Transfer) will work with the newer versions of MySQL, It's defiantly worth checking them out. Rob Can anyone recommend an ORM that works with MySql? ----- Excess quoted text cut - see Original Post for more -----

Transfer most definitely does. Supported on 4.1+ Mark > I think most of the popular ORM's (Reactor and Transfer) will work with the newer versions of MySQL, It's defiantly worth checking them out. > > Rob > > Can anyone recommend an ORM that works with MySql? -- E: mark.mandel@gmail.com W: www.compoundtheory.com

Reactor does also (same versions I believe). ----- Excess quoted text cut - see Original Post for more -----

> Reactor does also (same versions I believe). Reactor's support for MySQL 4.1 is not as good as its support for MySQL 5. I wrote the initial MySQL 4.1 support and it had numerous holes, many of which have been filled in by other contributors since. That's really because Reactor relies on database introspection and MySQL 4.1 just doesn't provide very good support for that. Transfer takes a much simpler approach to handling the database so it is not as dependent on the capabilities of the database. That's why Reactor doesn't require you declare objects or properties - it can introspect them - whereas Transfer does require you to declare. It's a trade off. I've found when working with legacy DBs, I've had to declare all the properties anyway - with Reactor - since I usually want to alias them. In other words, Reactor gave me no benefits from the introspection. I didn't use its automatic validation either, preferring to roll my own. And since Reactor used to be slower than Transfer, I switched. Reactor has made great strides in performance since but overall I've grown tired of the ActiveRecord pattern and prefer the clean separation in Transfer. Hope that helps? -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood