|
Plorkyeran posted:Oh no! Storing a bunch of copies of a few paragraphs! No one could possibly afford to store an extra megabyte for a large site with many translations! I work for a large site with many translations. I'm assuming you don't.
|
#
?
Aug 25, 2010 06:45
|
|
|
|
| # ? May 31, 2024 10:55 |
|
|
If you are trying to suggest that you have enough translations and text to translate that the storage space is in any way worth caring about, I'm going to call bullshit.
|
|
#
?
Aug 25, 2010 08:05
|
|
|
Plorkyeran posted:If you are trying to suggest that you have enough translations and text to translate that the storage space is in any way worth caring about, I'm going to call bullshit. As was said before, storage space doesn't really have anything to do with it. In the past I have stored translations in a table that contains: name, category, language, and the text. Primary key can be name,category,language. User goes to a certain part of the app, you can grab all the messages for that category. Make a utility class that is easy to access that ideally pulls them from memcache: Messages.get("SOME_LABEL", "Calendar", "en_US").
|
|
#
?
Aug 25, 2010 08:34
|
|
|
Well yes, and I already agreed that there are potential performance issues and that you should hash them if it does turn out to be a problem, and I would rather hope that anyone working on a site large enough that the performance impacts are foregone would have to ask basic questions about how to handle translations. Is there some problem caused by very long keys other than potential slow performance and the extra storage space?
|
|
#
?
Aug 25, 2010 08:48
|
|
|
Plorkyeran posted:Well yes, and I already agreed that there are potential performance issues and that you should hash them if it does turn out to be a problem, and I would rather hope that anyone working on a site large enough that the performance impacts are foregone would have to ask basic questions about how to handle translations. Is there some problem caused by very long keys other than potential slow performance and the extra storage space? Potential slow performance is much more likely to be a problem than extra storage space. Also, 400-character keys are just a big pain in the rear end to work with. A key like "terms of service" is going to be a lot easier to remember, and a lot more contextually relevant whenever the copy needs to change, than a paragraph of legalese.
|
|
#
?
Aug 25, 2010 09:11
|
|
|
Plorkyeran posted:Well yes, and I already agreed that there are potential performance issues and that you should hash them if it does turn out to be a problem, and I would rather hope that anyone working on a site large enough that the performance impacts are foregone would have to ask basic questions about how to handle translations. Is there some problem caused by very long keys other than potential slow performance and the extra storage space? There are two things I don't understand: why you're freaking out and secondly and why inefficiency is tolerable. The argument that you're making is, "The only thing wrong with storing these humongous keys is that more disk space is used, CPU load is increased, and every single request is slower!" In that case, you're absolutely right. Those things do happen if you do that. Except that I'd get fired if I had that kind of attitude.
|
|
#
?
Aug 25, 2010 16:33
|
|
|
A primary key rule is that it should never ever change. This is a rule that should result in a caning if it is broken. I have seen so many access databases that used a first/last name or a company name as a primary key and wanted to shoot myself each time. Totally ignoring storage concerns, using text that may change in the future for the key in this case is pretty bad design. It might not be the primary key in this case, but its pretty close. Using a hash of that text for the key is also a bad idea. Whenever you want to change the text on the website, you will not only need to make changes to your php files, but also make changes to your database which might involve generating a new hash.
|
|
#
?
Aug 25, 2010 16:46
|
|
|
Begby posted:Totally ignoring storage concerns, using text that may change in the future for the key in this case is pretty bad design. It might not be the primary key in this case, but its pretty close. Using a hash of that text for the key is also a bad idea. Whenever you want to change the text on the website, you will not only need to make changes to your php files, but also make changes to your database which might involve generating a new hash. Why would you need to modify the php or database if translations are provided by users (or google)?
|
|
#
?
Aug 25, 2010 16:58
|
|
|
Mackerel, the Thief posted:Why would you need to modify the php or database if translations are provided by users (or google)? I am talking about modifying the original text. Like if someone says to add a sentence to the paragraph, and you are using said paragraph to look up translations in a database. In that case you would have to modify the original paragraph and the DB.
|
|
#
?
Aug 25, 2010 18:03
|
|
|
Begby posted:I am talking about modifying the original text. Like if someone says to add a sentence to the paragraph, and you are using said paragraph to look up translations in a database. In that case you would have to modify the original paragraph and the DB. If you modify the original text and your translation framework doesn't invalidate the old translations, then your translation framework is broken. The point of keying based on the original text is specifically so that you have to at least look at all the translations when you make a change, and hopefully avoid having out-of-date translations presented to users.
|
|
#
?
Aug 25, 2010 18:09
|
|
|
I'm in way over my head here. Basically I'm trying to figure out how to add/replace text before the very first <h3> of a document. I've been told to check out php preg_replace and RegEx. Will these be able to do what I would like?
|
|
#
?
Aug 25, 2010 20:17
|
|
|
This could go in the SQL thread as well, but I had yet another coding theory question: How much to do you do in a MySQL query versus PHP? The question came to me while dealing with a date format, and realizing I needed to change the spaces to non-breaking spaces. So right now I have DATE_FORMAT(time,'%r'). (note: I realize there are ways around this (like "%h:%m:%s %p") but it brought me to the theory question, which has less to do with this specific instance) To change the space inside %r to non-breaking spaces I have two options: PHP: str_replace(' ',' ',$result) MySQL: REPLACE(DATE_FORMAT(time,'%r'),' ',' ') Now, the boss has said, use PHP to cut down on MySQL server load (I honestly don't know what the load is, but odds are it's not worth caring about at this point), and he says PHP can generate the date display faster that MySQL can, by throwing the timestamp into a date('format',strtotime($result)) call. Generally, I've tried to do as much as I can in the query, including concatenations, etc., but I wanted to check in and see what y'all think.
|
|
#
?
Aug 25, 2010 20:56
|
|
|
A database is used for storing and retrieving data. PHP is a hypertext preprocessor. Since this is just formatting for the user, you should do it in PHP.
|
|
#
?
Aug 25, 2010 21:06
|
|
|
micropenis posted:I'm in way over my head here. Basically I'm trying to figure out how to add/replace text before the very first <h3> of a document. I've been told to check out php preg_replace and RegEx. Will these be able to do what I would like? Normally I'd say "don't parse HTML with regexes!", because you shouldn't parse HTML with regexes. But you aren't parsing, you just need to insert some text that is totally not markup before a tag, right? $result = preg_replace('/<h3>/', 'Stuff before the tag and also the <h3>', $variable, 1); The 1 at the end limits it to one replacement. This is untested, you might need to escape the brackets. I'd say you could use str_replace instead, but it doesn't seem to have a mechanism to limit the number of results. Golbez posted:This could go in the SQL thread as well, but I had yet another coding theory question: How much to do you do in a MySQL query versus PHP? That's an awful reason. But it should still be done in PHP. You're formatting it for output, right? It's not the database's job to format things for output, that's the job of the thing that will actually perform the output. e: drat you, Doctor rear end in a top hat!
|
|
#
?
Aug 25, 2010 21:08
|
|
|
Golbez posted:Now, the boss has said, use PHP to cut down on MySQL server load (I honestly don't know what the load is, but odds are it's not worth caring about at this point), and he says PHP can generate the date display faster that MySQL can, by throwing the timestamp into a date('format',strtotime($result)) call. I'm really against doing any formatting in SQL since it violates MVC. Data should be separate from presentation. Beyond that, your boss is right, PHP should (e: most of the time) be able to handle the formatting with much less server stress than SQL.
|
|
#
?
Aug 25, 2010 21:10
|
|
|
Trying to upgrade PHP at work (we're running 5.2.5 :X) and it seems that Zend Optimizer doesn't support PHP 5.3.x? Are they holding out for PHP 6 or what? This essentially means that no web host can run PHP >= 5.3.0, which is already pretty old. Not sure if this is the right place for this but it looks like I have no alternatives, any suggestions?
|
|
#
?
Aug 26, 2010 09:46
|
|
|
A couple of my functions lately have run a query then returned the resource directly, rather than an array of stuff, because I want to loop over it in the receiving area without having to do it twice. For example...php:<?
$result = do_query();
while ($row = mysql_fetch_assoc($result)) { stuff }
function do_query() {
return mysql_query('select * from foo');
}
?>php:<?
$array = do_query();
foreach($array as $row) { stuff }
function do_query() {
$result = mysql_query('select * from foo');
$a = array();
while ($row = mysql_fetch_assoc($result)) { $a[] = $row }
return $a;
}
?>(on a side note, I've tried just doing "while ($a[] = mysql_fetch_assoc($result)) { }" but I get a blank entry at the end of $a, which, having to remove that, negates the savings in code conciseness)
|
|
#
?
Aug 26, 2010 14:48
|
|
|
Golbez posted:More code, and two loops, but I'm passing around an array rather than a resource. And this feels like it's impure somehow, like I'm doing it wrong. Am I making a big deal out of nothing, or is passing resources somehow frowned upon? I think you are making a big deal out of nothing. I would return the resource, if doing so calls for less looping. (I wouldn't usually write a function whose sole purpose is to perform a specific query and return the result, though.)
|
|
#
?
Aug 26, 2010 15:10
|
|
|
I think if you answer the question: What happens to my memory footprint if the query returns 10,000 (largish) records? You'll have the answer to which is better. Just remember to free the result outside your function. Or use PDO. Also 'negates the savings in code conciseness': less characters typed is not a sensible metric of code quality.
|
|
#
?
Aug 26, 2010 15:11
|
|
|
Kidane posted:Trying to upgrade PHP at work (we're running 5.2.5 :X) and it seems that Zend Optimizer doesn't support PHP 5.3.x? Are they holding out for PHP 6 or what? This essentially means that no web host can run PHP >= 5.3.0, which is already pretty old. I honestly don't think I have ever known one of our web hosts to run Zend Optimizer. Is there a particular reason why you need it? Do you have encrypted scripts from someone else you need to run? I would assume they would update it soon, or that demand for Zend Guard is so low that it doesn't make financial sense for Zend to stay on top of it.
|
|
#
?
Aug 26, 2010 15:33
|
|
|
Begby posted:I honestly don't think I have ever known one of our web hosts to run Zend Optimizer. Is there a particular reason why you need it? Do you have encrypted scripts from someone else you need to run? I would assume they would update it soon, or that demand for Zend Guard is so low that it doesn't make financial sense for Zend to stay on top of it. I've only had one user request Zend be installed on my servers. Everyone else uses ioncube.
|
|
#
?
Aug 26, 2010 15:47
|
|
|
I don't think I normally post straight coding questions here, but this one...php:<? $i = -1; echo ' and in role '.($i == -1)?'not us':'poop'; ?> In fact, I just changed $i to 1 and I still get 'not us'. So... huh? Now, if I wrap the ternary block in parentheses, the whole shebang works fine. But why? And why is it ignoring the first part of the string? Golbez fucked around with this message at 16:00 on Aug 26, 2010 |
|
#
?
Aug 26, 2010 15:58
|
|
|
Golbez posted:I don't think I normally post straight coding questions here, but this one... http://www.php.net/manual/en/language.operators.precedence.php The string concatenation operator has higher precedence than the ternary operator. What is happening is that the first 'argument' to ?: is the string ' and in role ', concatenated on the right with a Boolean. It will always evaluate to true as a Boolean.
|
|
#
?
Aug 26, 2010 16:00
|
|
|
Hammerite posted:http://www.php.net/manual/en/language.operators.precedence.php Thanks. That's some craziness, I have hundreds of ternary time bombs that I now need to make sure are properly wrapped. Edit: Turns out all the others are just fine, I guess I probably ran into this before and the body forgets pain. Golbez fucked around with this message at 16:05 on Aug 26, 2010 |
|
#
?
Aug 26, 2010 16:01
|
|
|
Given the problem is the concatenation operator, would using:code:
|
|
#
?
Aug 26, 2010 18:20
|
|
|
Yay posted:Given the problem is the concatenation operator, would using: Using commas works, because when you're using , you're sending multiple arguments to echo, and the comma has the lowest precedence of all. (If it didn't, sending function arguments would be a nightmare)
|
|
#
?
Aug 26, 2010 19:11
|
|
|
Yay posted:Given the problem is the concatenation operator, would using: Yes, code:
|
|
#
?
Aug 26, 2010 19:12
|
|
|
Yay posted:Speculating about crap like this, I realise how much I miss having a repl shell. http://www.phpsh.org/ Hmm, I could swear the regular interactive mode used to work like a really terrible REPL that crashed as soon as you did anything wrong, but I must be thinking of something else.
|
|
#
?
Aug 26, 2010 19:36
|
|
|
Golbez posted:
The thing that makes me a bit wobbly about this is that it doesn't keep the controlling layer agnostic of the data it receives. It must receive a mysql resource. Returning the resource does give you a bit more control and it will always be a bit faster, but what happens if you were to upgrade to PDO or install memcached? You then have to modify code in a lot of places as opposed to just in your models. That's why I personally like the latter code better, but it's really up to you and your situation.
|
|
#
?
Aug 26, 2010 23:07
|
|
|
Mackerel, the Thief posted:The thing that makes me a bit wobbly about this is that it doesn't keep the controlling layer agnostic of the data it receives. It must receive a mysql resource. There is a way to avoid this being a problem. Namely, instead of using the mysql functions for looping through resultsets in your application code, you create your own wrapper function and call that instead. That way, it doesn't matter that you are returning a mysql resource. If you decide to change to another way of communicating with your database, you can just update the code in your wrapper function. It doesn't matter that a different type of resource is being returned, because it's still being dealt with by your functions and it makes no difference as far as the code that uses those functions is concerned.
|
|
#
?
Aug 27, 2010 01:06
|
|
|
Begby posted:I honestly don't think I have ever known one of our web hosts to run Zend Optimizer. Is there a particular reason why you need it? Do you have encrypted scripts from someone else you need to run? I would assume they would update it soon, or that demand for Zend Guard is so low that it doesn't make financial sense for Zend to stay on top of it. I ASSumed a lot of people used it but if that's not the case then this should be easier. I was going off some of the more vocal posts on the Zend forums where people are clamoring for 5.3.x support. Thanks!
|
|
#
?
Aug 27, 2010 04:06
|
|
|
I'm kind of between projects, having done a big one and now waiting for them to explain the newer ones, so I've been taking a lot of time to go over my code on the last project, explaining most of my recent posts. Anyway, another brainstorming/coding theory one: Should a function hold more than one query? I was looking through stuff like my chat archive function, where first it copies (with insert...select) lines from the temporary table to the main table, and then deletes lines from the temporary table. And I was looking at that and thinking, should this contain two queries, or should I split them out? Each function has a query and each query, a function? And, secondarily, should these functions *only* contain the query code? So that even if I have a function with a single query, if it's doing anything other than running that query, the query should be in another dedicated function? This isn't necessarily specific to PHP, I suppose. Edit: and, I've taken to using COUNT(*) and mysql_result($result,0,0) to easily find out how many rows there are. But when it's a simple boolean (i.e. either there's 1 row or 0 rows) I still do return mysql_num_rows($result) (and, actually, I do (bool)mysql_num_rows for some reason). It's kind of been a mental thing - a mysql_result means it's a count, a mysql_num_rows means it's a boolean. ... Does this seem stupid to anyone else, because I sometimes wonder it as I browse. Golbez fucked around with this message at 14:39 on Aug 30, 2010 |
|
#
?
Aug 30, 2010 14:36
|
|
|
Golbez posted:And I was looking at that and thinking, should this contain two queries, or should I split them out? Each function has a query and each query, a function? I don't get why you would think this has to be the case. A function is a block of code that carries out some task you want done. That might involve performing a query, or it might not, or it might involve several queries. Why should there be limit of one query to every function?
|
|
#
?
Aug 30, 2010 15:15
|
|
|
Hammerite posted:I don't get why you would think this has to be the case. A function is a block of code that carries out some task you want done. That might involve performing a query, or it might not, or it might involve several queries. Why should there be limit of one query to every function? I dunno, I got it in my head that it could be considered cleaner. Instead of ... php:<?
function DoStuff($ID)
{
mysql_query('insert ... select');
mysql_query('delete from...');
}
?>php:<?
function DoStuff($ID)
{
CopyChatLines($ID);
DeleteChatLines($ID);
}
?>
|
|
#
?
Aug 30, 2010 15:26
|
|
|
Golbez posted:But I guess having reusable queries only really matters if they are, well, reused. This is prematurely splitting them out. Agree. However, one could say that splitting code out into functions "unnecessarily" (ie. those functions are only ever called from one place) causes you to become more aware of their existence, and more likely to reuse them, than if they were buried in some function.
|
|
#
?
Aug 30, 2010 15:36
|
|
|
Golbez posted:and keeping the actual functions free of query code, relegating that to specific query functions. But I guess having reusable queries only really matters if they are, well, reused. This is prematurely splitting them out. There is nothing concrete about how to split up functions, don't overthink it, nor is there a rule saying that a function has to be used more than once. By far the most important thing though is that your code is readable and maintainable. If a function gets to be too large, it might make sense to split it into smaller functions, then call those functions in order from some master function. I think that is a design pattern with some fancy name, but who cares. It might make sense to create a class with private methods to accomplish this, or at least pretend private methods depending on what version of PHP you are stuck with. Personally I prefer to work with code that is split into a lot of classes, each with a clearly defined purpose. Then within those classes have single task methods with clear self documenting names. Again, this is just my personal preference, do what works for you.
|
|
#
?
Aug 30, 2010 16:11
|
|
|
Begby posted:It might make sense to create a class with private methods to accomplish this, or at least pretend private methods depending on what version of PHP you are stuck with. Well, if this were a class/object, then I would probably have separate functions for each query, my mind just works easier that way when dealing with a class. But, and I've said this here before with much pain, they don't use classes here so I'm dealing with 1030 lines containing fifty functions. Not massive, but among the larger projects I've done (note that the number doesn't include the 2000 lines of javascript). I miss objects.
|
|
#
?
Aug 30, 2010 16:38
|
|
|
Hammerite posted:There is a way to avoid this being a problem. Namely, instead of using the mysql functions for looping through resultsets in your application code, you create your own wrapper function and call that instead. That way, it doesn't matter that you are returning a mysql resource. If you decide to change to another way of communicating with your database, you can just update the code in your wrapper function. It doesn't matter that a different type of resource is being returned, because it's still being dealt with by your functions and it makes no difference as far as the code that uses those functions is concerned. Or instead of reinventing the wheel you use PDO so other people that read your code don't think you are crazy.
|
|
#
?
Aug 30, 2010 18:51
|
|
|
fletcher posted:Or instead of reinventing the wheel you use PDO so other people that read your code don't think you are crazy. What does what we were talking about have to do with PDO versus proprietary database classes or functions? You would still have to work with resultset objects, or whatever the equivalent is when using PDO. By the way - if your response to that is "PDO is so wonderful that you'll never need to use anything else, just explicitly use PDO instead of any kind of wrapper functions" then a) I don't buy it, b) I've seen example PDO code that you and others have posted and in my opinion it looks pretty ugly, and harder to understand than the code I make use of for performing queries.
|
|
#
?
Aug 30, 2010 22:33
|
|
|
|
| # ? May 31, 2024 10:55 |
|
|
fletcher posted:Or instead of reinventing the wheel you use PDO so other people that read your code don't think you are crazy. PDO is nice and all, but you still need to write a half-dozen lines of code to do anything useful. I use a set of sprintf-like wrapper functions that automatically escape arguments, run the query, and return the first field of the first result, or the first result row as an array, or the result set, etc.
|
|
#
?
Aug 31, 2010 00:45
|
|
