Hi Benjamin, > Lets say I change a field called name to first_name. Then I rebuild > the models. fooPeer::NAME will no longer exist. Do I then manually > define that constant in a peer class?
Either that or search and replace. Personally, I tend to search and replace whenever possible. In relation to using constant vs hard coding, it is much easier to search for 'fooPeer::NAME' than just 'name'. > Lets say I sell the site to a corporation who only uses the foo > database, where my application is currently using the bar database. > Is there ever a situation where the field names would change based on > the database engine being used? Of course. I've worked in a PHP project that is deployed on several different environments that have different columns. So same web app, same database engine, but some tables have different columns for different clients. And I still have systems that I developed 6-7 years ago (web based but obviously before Symfony) for companies that I'm still being asked from time to time to make changes, improve, and maintain. I've experienced changing column names, table names, database engine, columns data types, just name it. Why do they ever change? Because business requirements change all the time. Well coded systems are easy to adapt to changing requirements. > I can definitely see the benefits, but like I said, I don't see myself > changing field names. I hope now you can see it On Thu, Mar 26, 2009 at 9:31 PM, Benjamin <[email protected]> wrote: > > That all makes sense. Here's a question.. er two. > > Lets say I change a field called name to first_name. Then I rebuild > the models. fooPeer::NAME will no longer exist. Do I then manually > define that constant in a peer class? > > Lets say I sell the site to a corporation who only uses the foo > database, where my application is currently using the bar database. > Is there ever a situation where the field names would change based on > the database engine being used? > > I can definitely see the benefits, but like I said, I don't see myself > changing field names. > > On Mar 26, 3:17 am, Sid Bachtiar <[email protected]> wrote: >> Fixing misspelled table names from previous developer, changing table >> names prefixes, configurable table names for Symfony plugins, easier >> to grep/search/replace, etc. Not many reasons but it is still a good >> practice. There is always reason to go against Abstraction when you >> writing code because it is 'extra' work ... it is mostly appreciated >> by the next guy reading/using it. >> >> To make things more readable (if I have to write a query instead of >> using Criteria object), I usually do something like: >> >> $tbl_user = UserPeer::TABLE_NAME; >> $sql_string = "SELECT * FROM $tbl_user"; >> >> (of course the above should be written with Criteria object, but just >> to illustrate) >> >> >> >> >> >> On Thu, Mar 26, 2009 at 8:19 PM, Benjamin <[email protected]> wrote: >> >> > This question may be unrelated to symfony, and more related to >> > database abstraction, but I'm wondering why I should pull the table >> > names from the model. I've been programming for a long time and have >> > never seen anyone need to use dyamic table names except when they have >> > prefixes on them that can change. >> >> > So, this is a pain to type out: >> >> > public static function getUserLabelsWithPasswordCounts($userId) { >> > $query = "SELECT >> > " . PasswordLabelPeer::NAME . ", >> > (SELECT COUNT(*) FROM " . >> > PasswordLabelPasswordsPeer::TABLE_NAME . " WHERE " . >> > PasswordLabelPasswordsPeer::LABEL_ID . " = " . PasswordLabelPeer::ID . >> > ") AS pcount >> > FROM >> > " . PasswordLabelPeer::TABLE_NAME . " >> > WHERE >> > " . PasswordLabelPeer::ID . " = '$userId' >> > ORDER BY >> > " . PasswordLabelPeer::NAME . " ASC"; >> >> > $con = Propel::getConnection(); >> > $pdo = $con->prepare($query); >> > $pdo->execute(); >> >> > return $pdo->fetchAll(PDO::FETCH_OBJ); >> > } >> >> -- >> Blue Horn Ltd - System Developmenthttp://bluehorn.co.nz > > > -- Blue Horn Ltd - System Development http://bluehorn.co.nz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
