Thank you Sid, Excellent answers :)
On Mar 26, 5:29 am, Sid Bachtiar <[email protected]> wrote:
> 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 Developmenthttp://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
-~----------~----~----~----~------~----~------~--~---
