Jump to content

kicken

Gurus
  • Content Count

    3,650
  • Joined

  • Last visited

  • Days Won

    101

kicken last won the day on February 24

kicken had the most liked content!

Community Reputation

513 Excellent

2 Followers

About kicken

  • Rank
    Wiser? Not exactly.

Contact Methods

  • Website URL
    http://aoeex.com/

Profile Information

  • Gender
    Male
  • Location
    Bonita, FL
  • Age
    33

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. $_SERVER['REQUEST_METHOD'] is a string value indicating what HTTP verb was used. To check for a POST request then you need to compare to the string "POST" not the $_POST array. if ($_SERVER['REQUEST_METHOD'] === 'POST'){ //... }
  2. Rather than taking your list of zip codes and doing another query, you could just join the users table in your original query. It would make things easier and more efficient. SELECT u.* FROM users u INNER JOIN ( SELECT zip, (3958*3.1415926*sqrt((latitude-?)*(latitude-?) + cos(latitude/57.29578)*cos(?/57.29578)*(longitude-?)*(longitude-?))/180) as distance FROM zip_codes ) zipDistance ON zipDistance.zip = u.ZIPCODE WHERE zipDistance.distance < ? ORDER BY zipDistance.distance If your $zip variable comes from another query that looks up a user-supplied zip code you could handle that with a join also and simplify your parameters. $sql = ' SELECT r.userId, r.firstName, r.lastName FROM ( SELECT u.userId, u.firstName, u.lastName, (3958*3.1415926*sqrt((userZip.latitude-targetZip.latitude)*(userZip.latitude-targetZip.latitude) + cos(userZip.latitude/57.29578)*cos(targetZip.latitude/57.29578)*(userZip.longitude-targetZip.longitude)*(userZip.longitude-targetZip.longitude))/180) as distance FROM users u INNER JOIN zip_codes targetZip ON targetZip.zip = ? INNER JOIN zip_codes userZip ON userZip.zip=u.ZIPCODE ) r WHERE r.distance < ? ORDER BY r.distance '; $zip = '12345'; //User input $radius = 30; $stmt = $this->db->prepare($sql); $stmt->bind_param('sd', $zip, $radius); $stmt->bind_result($userId, $firstName, $lastName); $stmt->execute(); $userList = []; while ($stmt->fetch()){ $userList[] = [$userId, $firstName, $lastName]; }
  3. I missed a comma between zip and the distance calculation in the inner select query. As a result it's parsing it as a function call instead of as separate columns. Add a comma between zip and ( in the inner select.
  4. Don't do that. Not in the actual table at least. Some people recommend this stupidity to try and avoid name collisions in their queries (such as two tables have a Label column) but such issues can be easily handled using the table.column syntax in your query rather than cluttering up column names in the table. SELECT o.Label as o_label, s.Label as s_label FROM order o INNER JOIN status s ON s.Id=o.Status One of the applications I work on was original designed using a scheme like that where every column has a table specific prefix to it and it's super annoying (long names, broken autocomplete) for no real benefit. I've been slowly undoing that when I can and just giving the columns nice simple names. I'd also suggest just using the full table name in your constraint names rather than some alias. It makes things very clear when someone 6 months later needs to decipher things.
  5. There are a few reasons you might want to know the name (index hints, changing the index, etc), but all are fairly rare so it's not really important that you name them explicitly. If you need the name, you could always look it up later. I tend to name my indexes and constraints just to be explicit. I use the format IX_table_name_column_name to keep things simple.
  6. Maybe just adding another join to your "complicated" query that connects the articles table.
  7. If it's a problem, I'd probably just drop the constraint. If it's important, handle it in your code otherwise don't worry about it. I'm not sure what a different database might provide as solutions to your issue. Only other one I really use is SQL Server and haven't looked into anything like this. The closest situation I have is with a DisplayOrder column which is typically set to a unique 1..n range value by the application. Having a duplicate isn't really a problem though so I don't bother enforcing that with a constraint or code.
  8. More or less for most use cases, as far as I understand them. Arrow functions do not create their own this and arguments variables so they will inherit those of the parent context. This is usually what a person wants to happen anyway so it makes them more convenient to use and their syntax is shorter. There are a couple other things they handle differently according to MDN. new.target and super are also not defined, neither of which are likely to be used all that often imo. I didn't even know new.target was a thing until I read that page. Not having their own this property makes them not useful in some situations, and apparently they can't be used as a generator using yield for some reason.
  9. Move your distance calculation into the SELECT list so it's a field and remove the WHERE clause. Then wrap your query in an outer query and apply your WHERE and ORDER BY clauses to that query. While your at it switch to a prepared query with parameters rather than concatenation to prevent and potential user input problems. Looks like maybe your using mysqli so I showed that option below. $sql = ' SELECT DISTINCT zip FROM ( SELECT zip (3958*3.1415926*sqrt((latitude-?)*(latitude-?) + cos(latitude/57.29578)*cos(?/57.29578)*(longitude-?)*(longitude-?))/180) as distance FROM zip_codes ) r WHERE r.distance < ? ORDER BY r.distance '; $stmt = $this->db->prepare($sql); $stmt->bind_param('dddddd', $zip->latitude, $zip->latitude, $zip->latitude, $zip->longitude, $zip->longitude, $radius); $stmt->bind_result($rowZip); $stmt->execute(); $zip_codes = []; while ($stmt->fetch()){ $zip_codes[] = $rowZip; } return $zip_codes;
  10. Open your browsers development console (F12) and disable the use of cache (Network tab -> [X] Disable Cache) and see if that resolves the problem. If it does, you know it's a browser cache issue. If it doesn't, you know the problem lies elsewhere. Have you experienced the issue in multiple browsers, or have you only been using one?
  11. Yes. Instead of selecting the ID you could select the is_free field (if you do that) to make the permission check simple in that case. You could just select the article content too if you wanted. Unless your going to have really big articles it probably wouldn't make a difference doing it at the start vs after the permission check. You'd save a query at the expense of more memory usage.
  12. The issue I think requinix is trying to point to is that if the article doesn't even exist, you don't want to show a 'This is a premium article.' error, you want to display a proper 404/article not found error. If you just display 'This is a premium article' in both cases, that will lead to confusion and frustration for your users. If the article doesn't exist there's no need to do any extra work for determining if the user has a matching entitlement to go with that article so you can cut all that processing out and not waste time on it. Only if the article exists do you then need to worry about processing entitlements. Whether or not the article being free involves entitlement checks depends on what kind of solution you end up using for determining free. If it's just a flag on the article then you can skip the entitlements checks if that flag is true. If you do some free plan that everyone is a member of by default then you will need to do the checks. So your logic structure would essentially be best setup as Does article exist? No? Display 404 and quit Is the article free? Yes? Display article and quit Is the user entitled to the article? No? Display entitlement error and quit Display article. Unless you have a compelling reason to do otherwise, I'd probably just start out with requinix's is_free column suggestion to make things easy. If in the future you decide that's not good enough then you can refactor it into something else. I spent a few minutes trying to think of a reason not to do a simple is_free column and couldn't really come up with any scenario where more than that would be necessary. Don't nitpick your query count. One vs two queries will make absolutely zero noticible difference in the runtime of your code. If two queries make the program flow nicer, use two queries.
  13. https://developer.twitter.com/en/docs/accounts-and-users/follow-search-get-users/api-reference/get-users-lookup You have to authenticate your request, you can't just load up the URL.
  14. Just make sure each form has it's own set of <form> tags and inputs. Add hidden inputs that you can use to differentiate the forms if necessary.
  15. Because it highlights better specifically what you feel was missed. Maybe the person thought they answered your question but you're still unsure. It's better to just quote the relevant question/comment and ask for a clear answer, maybe with additional details. Post numbers might be nice, but there's plenty of ways to deal with not having them. I'm sure someone here could if motivated to, but it's not always that easy to just hack the code to some third-party application. Since a lack of post numbers is not a huge problem, there's not much motivation to spend a bunch of time fixing it.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.