[transfer-dev] Re: Database function calls?
Actually, my workaround is just about exactly the same thing you are doing. Unfortunately this uses the system datetime from CF, and not the DB. With a cluster of 3 CF machines and one DB machine this could result in 3 different times (if all the system times aren't synchronized properly). I am trying to stay away from triggers here to make the code mor eeasily deployable across different DB platforms, but do use the DB time - something like the following: INSERT INTO user( [...] user_datecreated, user_datemodified, [...] ) VALUES ( [...] now(), now(), [...]) I really don't want to start tinkering with the DB and adding triggers right now so I think I may just move forward using decorators till I get more comfortable with another alternate solution. -Cameron On Wed, May 27, 2009 at 8:06 PM, Bob Silverberg bob.silverb...@gmail.com wrote: Hi Cameron, Welcome to the party! If you are currently maintaining those timestamps via the database (e.g., via triggers), you can continue to do that. You just need to make sure that you specify refresh-insert and refresh-update on the appropriate properties. For example: property name=dateCreated type=date refresh-insert=true / property name=dateModified type=date refresh-insert=true refresh-update=true / If you are not maintaining that data via the database or you wish not to, you can use Transfer's event model to do it. I wrote a blog post quite awhile ago that describes how I do it (http://www.silverwareconsulting.com/index.cfm/2008/5/21/My-Take-on-Transfer-ORM-Event-Model-Examples--BeforeCreate-Example). Hopefully one of those ideas will work for you. Cheers, Bob On Wed, May 27, 2009 at 1:15 PM, Cameron Childress camer...@gmail.com wrote: I'm a little late to the party but just getting my feet wet with Transfer. I'm trying it out on an existing project that I'm updating and refactoring... Currently I use columns called dateModified and dateCreated in most tables in this app and I use the DB for datetime stamps. I could just set a default value on the column, but I don't think this will work for me in both cases, since both are set on insert and only one of the two is set on update. I could also use the client or CF server's datetime, but I usually prefer using the DB's datestamp so I don't have to worry about syncing time on all machines. Right now I am just using CF to set the datestamp, but was wondering if anyone had any better ideas? -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com -- Bob Silverberg www.silverwareconsulting.com -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Database function calls?
Yeah, that would be another way to solve the problem. In my case I suspect it would be easier just to spend a little time and get the time on all the servers in sync. This is one of those problems where I started by trying to wedge something into Transfer that it doesn't really do in a very natural way. In reality it may be easier to step back and solve the problem another way - like by adjusting the time sync on all the servers involved. -Cameron On Wed, May 27, 2009 at 11:08 PM, Bob Silverberg bob.silverb...@gmail.com wrote: Hmm, well, this may be a crazy idea, but here's what I'd do if I needed to accomplish what you are suggesting, which is to always return the same, synchronized datetime value regardless of which CF server the code was running on: I'd create a DateHelper object with a getNow() method that would return a synchronized datetime. I would then inject that object into my decorators. I could then call getNow() on the DateHelper from within my decorator and I would know that, no matter which CF server I was on, I'd get the same synchonized datetime value. I'd implement my DateHelper by having it query the database and return getdate(), which would work for now. If you ever decided to change your implementation to use another technique to get a synchonized datetime, you would just have to change the internals of the DateHelper object, and none of the rest of your code would be affected. Again, this isn't necessarily something that I'd do, but off the top of my head it sounds like it might address your requirement. -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Transfer ORM and table based objects
On Mon, Jun 15, 2009 at 2:44 PM, Josh Nathansonjoshnathan...@gmail.com wrote: I would say that yes, your statement is confirmed. Okay I also might add that having DTO's that are not 1 to 1, might indicate a less than optimal application model, that is doing one to one joins rather than compositing objects. Really, it primarily indicates working with a DB that's designed for many more purposes than a single CF application. [...snip...] If you are already aware of all this then I apologize for the digression from your original statement. I am. It's a trade-off. Really, it's more like the Engine definition is scattered in an existing database. I could break down the DTOs a little more, and I actually started going down that road as well, but after modeling out a few additional objects I realized it was just a lot of extra work with very little (relative) benefit. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Transfer ORM and table based objects
Doug- I have the same thoughts as far as benefits of using Transfer, even if I am just rolling all the data up into bigger non-transfer DTOs, but at a certain point all that extra work I'm doing around Transfer is defeating the purpose of having an ORM framework in the first place. I'm not saying there is a problem with Transfer, just that it's not well suited for the application I'm currently working on. I think that when you have control over the database and the application from the start, Transfer makes alot of sense. With a strangely normalized DB that's not designed just for this one application, I am finding it difficult to adapt Transfer to suit my needs. -Cameron On Mon, Jun 15, 2009 at 2:39 PM, Doug Boudedougbo...@gmail.com wrote: Cameron, I tend to develop the way you're describing as well, but here's how I figure Transfer into the mix... Okay, any service object is typically going to be a composite of underlying, simpler objects that DO have a 1 to 1 relationship to the db. For instance, if you are writing a smart userService cfc (service layer) that performs all kinds of tasks such as your user CRUD, authentication perhaps, calculating employee discounts, or who knows what, you must still at some point in the code interact with the user table and/or its related tables. Without an ORM, we do this with the sql in our queries, perhaps writing complex joins and the like in order to return the record sets we want, or by manually creating some dumber 1 to 1 objects. By tossing Transfer in the mix, however, what I have done is eliminate the need almost entirely to write any sql, to worry very much about handling transactions manually, and giving myself the ability to do some cool magical things like cascade deletes and saves. So, your transfer.xml file will define all of those one to one table relationships (not your smarter, more complex service layer objects), and then your smart CFCs will simply manipulate and utilize those Transfer objects in lieu of any SQL or hand written beans or other simple objects that you need. This is how I see it, anyway. In addition, Transfer gives you the wonderful ability to still write sql when you want/need to, only in a slightly modified syntax called TQL. Leveraging this baby allows you to do anything you would in a query (pretty nearly anyway), plus giving you the ability to store a search without having to actually store the results or a lot of separate parameters; you generate TQL statement based on user criteria selections in your form, then store that TQL statement in your db for use later on. That's just one application for TQL that I have personally found and loved. Just my two cents. Doug Boude :0) On Mon, Jun 15, 2009 at 1:28 PM, Cameron Childress camer...@gmail.com wrote: So, I've been toying with Transfer off and on since CF.Objective, but I think I've come to a end of my exploration. I wanted to ping the like and make sure I'm not missing a solution here. I have an existing application I'm refactoring using ColdSpring and wanted to use Transfer too. However - most DTOs in this application do *not* have a 1-to-1 relationship to a table in the database. In fact, I think most projects I work on don't have DTOs with a 1-to-1 relationship to table in the DB (meaning user table = user.cfc). Alot of DTOs are composed of several DB tables joined together to represent a single DTO in the application. Transfer seems very well suited for applications which are designed to have a single table pair up with each DTO, but very poorly suited for applications where the DTOs are flat composites made from several DB tables. I wanted to confirm the above statement(s) and make sure I hadn't just misread the situation. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Transfer ORM and table based objects
On Mon, Jun 15, 2009 at 3:07 PM, Bob Silverbergbob.silverb...@gmail.com wrote: This is an interesting discussion. I was wondering, Cameron, if you'd be willing to share an example from your application so that we could see whether or not there's an elegant way to make Transfer fit with your model. Sure. This is a configuration DTO that contains about 10 properties from one table, and two text properties fields from another - all the properties are in one flat DTO. The existing application uses SQL something like this: SELECT sm.prop1, sm.prop2, sm.prop3, [...] s1.source_code as sourceLabel, s2.source_code as altSourceLabel FROMtable1 T1 LEFT JOIN sources s1 ON (T1.source_id = s1.id) LEFT JOIN sources s2 ON (T1.alt_source_id = s2.id) WHERE T1.id = cfqueryparam / Then all these columns would be set into DTO properties and the DTO is fed to a Flex application. Now I *could* just rewrite the SQL in TQL and be done with it. But why? I would still have to manually configure my DTO with the values returned. This is really just replacing my SQL with TQL and I'm not gaining much from my effort. I could also unflatten the DTO and create a SourceCode DTO, but it's only going to have one property - so why bother? That would allow me to make this into several DTOs composited together and define it all in the transfer.xml file. This would be cool since I'd be able to take advantage of all the setter getters Transfer automagically generates for me. But again, that's a ton of extra work for very little benefit. -Cameron -- Cameron Childress Sumo Consulting Inc http://www.sumoc.com --- cell: 678.637.5072 aim: cameroncf email: camer...@gmail.com --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
[transfer-dev] Re: Transfer ORM and table based objects
To clarify, the table I tried to cleverly rename as table1 with an alias of T1, was initially aliased sm in my code, not T1. Sorry if my invalid pseudocode is confusing. On Mon, Jun 15, 2009 at 3:34 PM, Cameron Childresscamer...@gmail.com wrote: SELECT sm.prop1, sm.prop2, sm.prop3, [...] s1.source_code as sourceLabel, s2.source_code as altSourceLabel FROM table1 T1 LEFT JOIN sources s1 --~--~-~--~~~---~--~~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups transfer-dev group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~--~~~~--~~--~--~---
