I was thinking of using this same coding style for the rest of my "User Profile" form, however, here is a "catch" that makes me wonder if Constants are such a good idea in a place like this after all...

In my database, I defined "user-bio" as VARCHAR(1024), so, if I only ever want to make this field smaller, then only having to update ONE CONSTANT is great.

However, the minute I forget about the Database, and accidentally give my long-winded Users 2,048 Characters - via BIO_MAX - to describe themselves, then all of that extra text will be lost?!

Some of you will say, "Well, Debbie, just don't forget!!" To which I'd say, "Program so you don't have to remember!"

My thinking is this...

Constants are great, but to assign a Field-Length Constant to every field in my "User Details" page might cause more headaches than just hard-coding field lengths.

There are Pros and Cons to each approach.

What do you think about the scenario I just described?

Sincerely,

Debbie

cpradio
—
2013-12-26T17:28:01Z —
#2

DoubleDee said:

What do you think about the scenario I just described?

That it has nothing to do with Constants... You could hard code the value of it and you have the same problem, but in all reality, it isn't really a problem. If you open up the limit without altering the database, you'll get a truncation error when you try to insert a value that exceeds the column size.

If you test each change (like you should), you'll discover this issue and fix it before it goes live. Even if you don't get a truncation error, if you test (like you should), you should see the truncation occurring. Either way, this isn't an issue with how you coded things, it is an issue if you fail to test your changes properly.

Cups
—
2013-12-26T17:59:24Z —
#3

Perhaps the question is "how can I link my PHP code restraint (string length) dynamically to my database schema so that it only exists in one place?".

DoubleDee
—
2013-12-26T18:27:48Z —
#4

Cups said:

Perhaps the question is "how can I link my PHP code restraint (string length) dynamically to my database schema so that it only exists in one place?".

I dunno.

Sounds like you have an idea...

Debbie

cpradio
—
2013-12-26T18:29:02Z —
#5

DoubleDee said:

I dunno.

Sounds like you have an idea...

Debbie

Not one that I would ever take seriously! That seems like a lot of overhead to me, I just don't buy that as a good solution. I don't know though, maybe there are people out there that do this, I for one wouldn't.

DoubleDee
—
2013-12-26T18:33:23Z —
#6

cpradio said:

That it has nothing to do with Constants... You could hard code the value of it and you have the same problem, but in all reality, it isn't really a problem. If you open up the limit without altering the database, you'll get a truncation error when you try to insert a value that exceeds the column size.

If you test each change (like you should), you'll discover this issue and fix it before it goes live. Even if you don't get a truncation error, if you test (like you should), you should see the truncation occurring. Either way, this isn't an issue with how you coded things, it is an issue if you fail to test your changes properly.

Seems like a rather harsh response.

When I remove the restrictions from my Form and enter a value which is too big, I get a success message, butt hings get truncated off. (No INSERT errors.)

One main reason for "config.php" script is that it allows me to tweak things "on-the-fly". So while I do test things, the very nature of my "config.php" script kind of goes against formal testing.

(I suppose down the road I could build a "Preferences Form" which takes my Constants and reconciles them against my Database, but that won't happen this go round...)

Also, my bigger point was, "Is there a benefit to associating a Constant with tons of Field Lengths, versus just a few obvious ones (e.g. "Bio Length", "Private Message Length", etc.)??"

Sincerely,

Debbie

cpradio
—
2013-12-26T18:51:17Z —
#7

DoubleDee said:

Seems like a rather harsh response.

Do you disagree that it is a lack of testing issue?

DoubleDee said:

When I remove the restrictions from my Form and enter a value which is too big, I get a success message, butt hings get truncated off. (No INSERT errors.)

You likely don't have a few settings enabled that would offer this functionality.
stackoverflow.com

One main reason for "config.php" script is that it allows me to tweak things "on-the-fly". So while I do test things, the very nature of my "config.php" script kind of goes against formal testing.

No it doesn't... That's an excuse for not wanting to test you alteration properly. From what I recall, I thought you used to be in QA? If a dev altered a configuration that was used in 6 parts of an application, would you not test all 6 parts and a few outside of those? You would. How is your own personal app any different?

I make many changes each and every day, I also look at what my changes will likely impact, what they shouldn't impact, and I hand that information off to our BA so she can ensure that what I think will be affected agree with what the requirements show or if there are things I found that they didn't know about, they can react to those accordingly.

DoubleDee said:

Also, my bigger point was, "Is there a benefit to associating a Constant with tons of Field Lengths, versus just a few obvious ones (e.g. "Bio Length", "Private Message Length", etc.)??"

Since you are working in a procedural format, constants are one of your best answers. What are you alternatives? Hard Code it (reusability sucks, and you can't easily search for all places to change it), don't validate it, enable truncation errors (catch the error, process accordingly).

DoubleDee
—
2013-12-26T19:22:41Z —
#8

cpradio said:

Do you disagree that it is a lack of testing issue?

Yes, BUT like I said above... I think well-designed systems help you to not hang yourself.

cpradio said:

You likely don't have a few settings enabled that would offer this functionality.
stackoverflow.com

No it doesn't... That's an excuse for not wanting to test you alteration properly.

From what I recall, I thought you used to be in QA? If a dev altered a configuration that was used in 6 parts of an application, would you not test all 6 parts and a few outside of those? You would. How is your own personal app any different?

No, actually I'm a BSA by day...

I do try and test things. Heck, insane testing has added a YEAR onto my website. If anything, I test too much?! :rolleyes:

While I see (and agree) with your point, you are leaving out the fact that...

1.) Sometimes Changes don't get QA'd in every place they need to be, thus things slip through. (That's the "Human Factor" and a big reality!)

2.) If you make it too easy to change things without any safe guards, sometimes humans forget to QA or QA the right things. (It is why God created "Referential Integrity"! If you would just "test" everything, you'd never need Foreign Key constraints my friend...)

cpradio said:

Since you are working in a procedural format, constants are one of your best answers. What are you alternatives? Hard Code it (reusability sucks, and you can't easily search for all places to change it), don't validate it, enable truncation errors (catch the error, process accordingly).

Here are my thoughts for v2.0...

Constants are beautiful, but like anything, should be used sparingly.

My "private_message" table defines the PM Body as "Text", so creating a Constant called "PM_MAX" makes sense, and I don't have to QA anything, because I would choose some insanely large value for the length...

By contract, my "member" table has a Profile field called "occupation" which is 40 characters. A Constant might be okay, BUT I have to remember if I change it from "40" to "60" to change the Database from VARCHAR(40) to VARCHAR(60)...

I cannot stress enough that I am the "Queen of Testing" my own code.

But I am also human, and humans make mistakes, and for me, I can possibly see myself changing "OCCUPATION_MAX" from "40" to "60" and forgetting to update the Database Table because most of my Constants do not touch the Database...

(If I leave things hard-coded for "Occupation", then I won't have to worry about said mistake, because if I change actual code then I ALWAYS test the heck out of things!!!)

Sounds lame, I'm sure. But just sayin...

Sincerely,

Debbie

cpradio
—
2013-12-26T20:00:46Z —
#9

DoubleDee said:

No, actually I'm a BSA by day...

Oops, my bad

DoubleDee said:

While I see (and agree) with your point, you are leaving out the fact that...

1.) Sometimes Changes don't get QA'd in every place they need to be, thus things slip through. (That's the "Human Factor" and a big reality!)

Sure, but then you fix them, test them, and deploy them. You can always look at integration tests too that run continuously so as changes are made, if it negatively impacts an existing test, that test will break.

DoubleDee said:

2.) If you make it too easy to change things without any safe guards, sometimes humans forget to QA or QA the right things. (It is why God created "Referential Integrity"! If you would just "test" everything, you'd never need Foreign Key constraints my friend...)

No, that comparison is flawed. Referential Integrity is a validation technique, not a QA technique. It simply validates what is provided is valid. It doesn't prove that part of the system works as designed.

DoubleDee said:

Constants are beautiful, but like anything, should be used sparingly.

I can agree with this.

DoubleDee said:

My "private_message" table defines the PM Body as "Text", so creating a Constant called "PM_MAX" makes sense, and I don't have to QA anything, because I would choose some insanely large value for the length...

I adamantly disagree with this. You should test everything! No matter how obscure the value is, it should be tested against.

DoubleDee said:

By contract, my "member" table has a Profile field called "occupation" which is 40 characters. A Constant might be okay, BUT I have to remember if I change it from "40" to "60" to change the Database from VARCHAR(40) to VARCHAR(60)...

Create documentation of the requirements so when you do make the change, go to your documentation, see that it affects a table as well, and ta da! Or test it... (or both)

DoubleDee said:

But I am also human, and humans make mistakes, and for me, I can possibly see myself changing "OCCUPATION_MAX" from "40" to "60" and forgetting to update the Database Table because most of my Constants do not touch the Database...

Of course, which is why you should test your changes. If you are going to edit anything, be sure you know what it affects before doing so. Otherwise, you'll be bug ridden in no time. Do a search for OCCUPATION_MAX throughout your project and be sure to hit all of those scenarios.

DoubleDee said:

(If I leave things hard-coded for "Occupation", then I won't have to worry about said mistake, because if I change actual code then I ALWAYS test the heck out of things!!!)

Not really, you just might forget to update one of the hard-coded locations. Try searching for 40 throughout your code and see how many false positives you might get. Or you may update the wrong location or not all locations. Plus hard coding still doesn't ensure you'll remember to update the column size...

:lol:, You'll make mistakes, heck I still make a few (and QA has been good to catch a few of them; and others not so well -- but they were complicated edge cases). Simply put, there isn't a right or wrong to your question, but keep in mind, running a test against code you are altering is always to your benefit regardless of how simple the change was to make.

DoubleDee
—
2013-12-26T20:14:02Z —
#12

cpradio said:

but keep in mind, running a test against code you are altering is always to your benefit regardless of how simple the change was to make.

A good reminder, even for me!! :tup:

Thanks,

Debbie

Mittineague
—
2013-12-26T23:31:16Z —
#13

When something is fresh in my mind I tend to tell myself "I'll remember that". But I have learned that after I'm away from it for a while I can easily forget.

That's why I have learned to use /*comments*/

Nothing like seeing

/* if this value is increased, ALTER the table */define("OCCUPATION_MAX", 40);

to jog my memory.

DoubleDee
—
2013-12-27T01:55:43Z —
#14

Mittineague said:

When something is fresh in my mind I tend to tell myself "I'll remember that". But I have learned that after I'm away from it for a while I can easily forget.

That's why I have learned to use /*comments*/

Nothing like seeing

/* if this value is increased, ALTER the table */define("OCCUPATION_MAX", 40);

to jog my memory.

Another good idea.

Thanks,

Debbie

oddz
—
2013-12-27T08:02:59Z —
#15

Not to mention in the real world there are going to be multiple hands on a project. No one is going to know what you know unless they have some sort of documention or comments as already described. One of the worse things in programming is to inherit some project from an incompetent developer who didn't know how to comment or write documentation or at the worse code / normalize a db. I know that is not relevant in your case but it is a real problem when dealing with projects that have hit multiple hands. In the real world of clients (besides yourself) it is not unordinary to come across project that have had over ten or twenty different developers. Each one one with a different skill level… which is why testing/QA is important. You never know what you might run into with others poor decisions/lack or foresight. Which is why it is important to test and have proper QA procedures set-up. Just saying… I know you are a one women army but that is not how it works in the real world.

DoubleDee
—
2013-12-27T18:50:22Z —
#16

oddz said:

Which is why it is important to test and have proper QA procedures set-up. Just saying… I know you are a one women army but that is not how it works in the real world.

Sir, yes Sir!!

Getting to work on the Constant Comments and updated Documentation immediately, Sir!! :lol:

(All of this advice and wisdom everyone at SitePoint has been subjecting me to over the last 3 years will either make me one hell of a Developer with one hell of an impressive website, OR kill me!!)

Thanks,

Debbie

Cups
—
2013-12-27T19:20:39Z —
#17

DoubleDee said:

I dunno.

Sounds like you have an idea...

Debbie

I might have an idea, but I was actually just paraphrasing your original question, and no, I do not have the answer to that question by the way.

So this might then be viewed as a question on how to manage that part of your Model code which talks directly to your database.

AFAICT, most popular Frameworks data access is governed by config files, ini files and the like.

In one direction they are picked up and used by the Model, but in the other direction they could be used by the View.

this is a snippet from an ini file from a framework wot I made myself a few years ago...

These values are extracted for data verification in one way (Model-ish), and for HTML form generation in the other (View)

In light of the above conversation about testing, I don't suppose it would be impossible to check the value in a config file against the db schema when a test suite is run.

Whether it would be worth the sweat is of course as said, debatable.

In light of the example I posted I suppose a lower level question really ought to be, "how is it that my view is able to send data to my database that has not passed some kind of verification?"

The example illustrated still does not do away with a hardcoded value for the length of the description, but at least sticks it in one place so you could reasonably check it vs your db schema on demand.

Maybe this is by the by -- and only relevant if your question was mainly concerned with the development stage -- but I found this SP article on Redbean fascinating and though I leafed through the Redbean docs at the time and saw no mention of its power when matched with Unit Testing, it would seem a good match.

John_Betong
—
2013-12-28T02:01:23Z —
#18

Debbie, try using a MVC approach where the raw View data is passed to a Model.

The Model is best thought of as a third-party external process with no access to the code and either saves or returns messages relating to invalid data.

DoubleDee
—
2013-12-28T02:29:46Z —
#19

John_Betong said:

Debbie, try using a MVC approach where the raw View data is passed to a Model.

The Model is best thought of as a third-party external process with no access to the code and either saves or returns messages relating to invalid data.

Sorry, but you and Cups are way out of my league on the last two posts.

Maybe someday I will learn OOP and MVC anc can d such things, but for now - and this thread - I am leaving my code as-is!!

Constants for things like PM Length or Bio Length where the DB Field is Text and I can tweak the length without having to touch the database, and hard-coded - for now - for fields like "PM Subject" where I really have no business changing that after it is built.

Sincerely,

Debbie

John_Betong
—
2013-12-28T02:57:29Z —
#20

OK if the MVC approach is too daunting then consider sending your raw user input data to a catch-all function that either returns TRUE on success or a text message detailing why the data could not be saved.