Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by NigelRel3

  1. You are trying to insert into 3 values for your insert statement and bind only 1.
  2. I've managed to sort of a simple REST test, which uses a standard model with a single field for the key. I've also managed to get Eloquent to deal with composite key models. Now I want to see how I can put them both together - in the simplest way possible! So i would like it to fit into the standard Route::resource('/Bin', 'RestBinController'); This only seems to expect a single parameter and so if I try /api/Bin/1/2 it doesn't recognise the path. I could split it out into the get/post... methods (and it may come down to this) but I wanted to check if I was missing something before I did this.
  3. I think it's better to maintain the same case anyway - using Linux a lot means you tend to get used to the fact that case matters in a lot of things (which is why table names can be case sensitive) I'm a fan of camel case and I think it makes things more readable - but inconsistent use of case for the same field can (IMHO) lead to confusion.
  4. Although consistency of names IMHO is important, just to clarify ( from https://dev.mysql.com/doc/refman/5.7/en/identifier-case-sensitivity.html ) Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases.
  5. You could build an array of conditions, where can take something like... $binT = \App\BinType::where([['binTypeID', '>', 1], ['sizeX', '<', 10]])->get(); So if you get to the end of all the possible conditions, you can make a choice of including the where only when you know there are criteria to use.
  6. Have you looked at using HTML5 required attribute - this will do a lot of the work for you!
  7. Surely the whole point of moving to Laravel is to integrate with the framework! If OP isn't going to use even parts of the functionality, then why bother with a framework in the first place?
  8. I have recently been learning Laravel and there is a large change of structure from using a pure PHP app to using the Laravel framework as it's intended. So the answer is (I think) there will be quite a bit of work to change your app over to using Laravel. Is it worth it? Difficult to tell, frameworks offer a lot of features, but if you don't need or use them then they can be overkill. The separation of the views from the controllers and models means that gone are the monolithic pages which handle the display and processing of data. The end result is a more focused set of scripts which help in development, you know if you want to change the display, you may only have to alter the view. This can be a bit more of a pain if your used to 'all my processing for page x is in file x', but helps in other ways.
  9. I'm not sure about some of these macros, I know it MAY make the code a bit more compact, but does it make it more maintainable?
  10. The error is very clear - mysqli_error expects a parameter - usually... mysqli_error($connection)
  11. TBH - this is what concerns me, you are asking questions about how to work with data and you are writing code which allows payments by credit cards. With all the issues about data breaches and insecure web sites, you are continuing with something which has possibly huge impact on people and their financial details. I'm looking for a junior role as a PHP programmer as I don't have any commercial experience in PHP and yet I see people writing code for web sites which makes me wonder! If your unsure about how something works, write a SMALL test for it, try it and see what happens. If this example fails then work out why, don't try and obfuscate the problem with all of the other stuff around it.
  12. Hmmm... as employeeId wasn't even mentioned in your first post, I can't see how the original code 'is the essence of things'.
  13. This is a good example of how badly layed out code can make development difficult. If you laid out the code using something like... if(condition) { someotherCode(); } The problems may become obvious.
  14. Can you post the actual code (or at least a cut down version) which shows the problem your having. This should work, but without the details it's difficult to comment on.
  15. Interested in what your attempting to achieve? Are you trying to get some form of failover, if so there are some more tried and reliable methods out there.
  16. One thing with this is as long as the databases sit on the same server, it's easier than using federated tables, but again, depends on your circumstances.
  17. In MySQL you can update several tables in the same statement... Update table1, table2 set table1.qty = table1.qty+1, table2.qty = table2.qty-1 where table1.id = table2.id If you also consider that a table could use the federated storage engine, this lets you have a table on remote databases, so each table in an update could be on a different database. There are all sorts of caveats with this sort of table (e.g. transactions are not supported) but if this is the best solution, then it may be worth trying.
  18. Yup - xmlns is for XML namespaces, this one is the default namespace as it doesn't specify a prefix. A quick Google finds...https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd which is probably what it should point at. The URI you have is a relative one which can be prone to getting out of date.
  19. One thing to think about is that although this query may not be the most optimal, it's also not the most frequently used - unless you have thousands of people joining at a time. If you had millions of users then it may be a slight issue. So it's not such a big deal to do it this way, although it's still interesting to see other solutions.
  20. Isn't product_id on two tables in your statement - should you precede it with the table name. Couple of things... Try and space out your SQL statements to make them easier to read, so select blah from blah where blah = bllah Also when you have long table names, use table aliases... select b.blah from blah_blah_blab b where b.blah = bllah makes it much easier to read (IMHO)
  21. What library are you using for the database access? You use DatabaseConnection::getConnection() to get the connection, so this should be defined somewhere. This will affect how the prepare and execute methods are called.
  22. Thanks - that's the sort of thing I was after.... Just a few points I think this is where some people get misled and think it is. They know enough about it being able to connect to multiple database vendors but not that this is just part of the work involved. Didn't know that, so will ensure that when I use it I make sure this is set properly. My understanding was that with MySQLi prepares, the result set fields where sent from the server to the client API using binary and using the correct data-types (as from http://php.net/manual/en/mysqli.quickstart.prepared-statements.php - Result set values data types). I thought PDO did this using ASCII and then converted the types at the client end. Nothing huge, but IMHO still something that was worth knowing. And finally... Which is where I think the real problem lies - unfortunately people seem to have this idea that anyone can write a web site using PHP. This is probably true, but how many of those sites are either still running after real world exposure and even those still running are probably prime targets for hacking. I will have to try and rebuild something from MySQLi to PDO and see how it goes. Although I'm currently trying to use Laravel and it uses Eloquent as an ORM - not that impressed and have resorted to running straight forward SQL rather than trying to work out how to do table joins and aggregates. My main goal was to understand the architecture of the framework and so RTFM of all it's components is a bit much for now.
  23. I've seen a few posts which recommend PDO over MySQLi and after a bit of reading it seems that PDO mainly comes out better due to more database brand connectivity. TBH - I have no real preference and have used MySQLi due to the fact I was connecting to MySQL. I suppose I should have a go with PDO so at least I can use it proficiently and be able to work with any code that's thrown at me (or more likely I'm thrown at :-/) One thing about the multi database connectivity that sort of puts me off though is that it is assumed that you simply change your database type and automagically everything works out of the box. This doesn't take the different SQL dialects into account and could involve quite some work to make it work again. So this sort of puts me off pushing this as an advantage! Is there any real winner between the two - if I was to start a new project for a client, should I be going down one path or the other? Other differences I'm aware of: PDO has named parameters as well as positional, MySQLi uses only positional. PDO uses client side prepares, MySQLi uses server side. MySQLi passes binary client-server (for most things), PDO uses strings. Any thoughts/suggestions/ideas would be helpful! Thanks
  24. You should also look into changing mysql_query to either mysqli or PDO.
  25. I've read about the differences of local storage and cookies and there seems to be little difference technically. Main things seem to be client side limitation, timeouts, older browser compatibility and data volumes. TBH I don't care about server side processing of this field, there isn't going to be much data I use for this sort of thing and I don't need timeouts. From the responses I've had it's more about what people would normally do as opposed to what you can do - which is more useful than anything ATM.
  • 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.