Jump to content

Stew_822

New Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Stew_822

  • Rank
    Newbie

Profile Information

  • Gender
    Male
  • Location
    I come from the land down under
  1. Stew_822

    How does $path variable know to go anywhere?

    Ah ok - I'm afraid I can't help you any further with that, I have no experience with bitcoins. I imagine you would need to use a function to send a message to the server, wait for the the server to respond, and then act based on the server's response.
  2. Stew_822

    How does $path variable know to go anywhere?

    G'day mate Good questions are asked by first defining what you want to do. To answer your question as you put it, the $path variable doesn't know how to go anywhere since it is simply a string (which is just a sequence of characters). You haven't told it to do anything, so it isn't going to do anything, which makes logical sense. If you let us know what you're trying to achieve, then I don't mind spending a few minutes helping you get there. Cheers, Stewart
  3. Stew_822

    Need Help with simple PHP program

    G'day mate Could you re-paste your code using the <> button? It's hard to read without formatting. Try to narrow the problem down as much as possible. Is your user input coming in as strings, and you're trying to use them as numbers? You can check using a var_dump. What are you trying to do? If you're trying to count the number of positive, even integers, you could do something like: $array = array( 1, -2, 3, 4, 5, 6.5 ); $positive_even_integers = array(); foreach( $array as $number ) { if( is_int( $number ) and $number >= 0 and $number % 2 == 0 ) { $positive_even_integers[] = $number; } } echo count( $positive_even_integers ); // should output 3 I find foreach simpler than using for, and also copying the elements from your original array to another array might be easier than deleting the elements from the original array. Then, you can just count the number of elements in the final array. When testing your code for bugs, assume the bug could be anywhere. If you're not sure if the array coming from your user input is valid, then overwrite it with an array of values that you know is legitimate. Then you might find your code will work, and you'll know the problem lies within your user input code, which is then where you would start looking.
  4. Hi guys, This isn't a question; more of a, hi, here's what I've been up to, maybe it's interesting to you. Excuse the lengthy post, I've been working on finding a neat implementation of how to represent the schema of a database (and from that, generate a usable database) and I think I've finally found it. I've been developing a website that enables users to create a virtual representation of their aquarium, add species to it and see how it pans out virtually before buying their fish and killing them. There is a lot of links between the different tables, eg. a species has a habitat, the users who collatorated to create the profile of the species. Users have their tanks; tanks have species; and so on. I don't like creating a table in SQL to materialise a relationship, so I'm designing my own database system for this project which uses files to store the data, and symlinks to create references to other pieces of data ('records', rather than 'rows'). It's a hobby project. I've been doing a lot of reading on designing databases and object oriented patterns, and I've come up with the following database system (which has a little way to go before it's usable). I've tried to make it double as a database abstraction layer so that if I find the performance ain't that great, I have the option of switching to SQL. On to the code; an example of creating some records and then finding them: // everything under the 'my' namespace is specific to the custom // database we're talking about. The my\database class isn't // anything special, it's just a class $db = new my\database(); // the $db->users variable is an instance of zest\database\handle $frank = $db->users->create(); $john = $db->users->create(); // $frank and $john are instances of zest\database\record $frank->name = "Frank the Farmer"; $john->name = "John Doe"; // you have to insert users before assigning them as references $db->users->insert( $frank ); $db->users->insert( $john ); $species = $db->species->create(); $species->common_name = "Platy"; // contributors is an array containing references to users $species->contributors = [ $user, $user2 ]; $db->species->insert( $record ); $species = $db->species->find( $species->id ); // it's all lazy loaded, which is OK because it's a flat file system echo $species->common_name; // Platy // you can load many at once - which would hopefully increase performance if swapping to mySQL $species->load( 'common_name', 'contributors' /* ... */ ); // or, being a little bit fancy here $species = $db->species->find( $species->id )->load( "common_name", "contributors" ); // you can search for species - not sure how performance would be for SQL queries though. // it might be better to implement SQL-style queries, but screw that - I have a life $species_list = $db->species->search( function( $record ) { if( $record->ph_lower > 4.5 and $record->ph_upper < 8 ) { return true; // and so add it to the list } else return false; } ); In the file my/database, which is basically a singleton that is the database object (not related to my database classes, but a convenience): <?php namespace my; class database { public $species; public $users; function __construct() { $root = "data"; $this->species = new \zest\database\handle( "$root/species", // folder you want to use to store records species\schema( $this ), // the schema of your database - how your records should look '\my\species\record' // the class you want the records returned as ); $this->users = new \zest\database\handle( "$root/user", user\schema( $this ) ); } } And finally, an example of a schema, which is usually the most confusing bit of a database mapper or ORM (my\species\schema): $schema = new \zest\database\schema(); $schema ->property([ 'name' => 'common_name', 'type' => new types\string(), 'required' => true ]) ->property([ 'name' => 'contributors', 'type' => new types\vector( new types\reference( $database->users ) ), 'default' => array() ]) //->behaviour( new behaviours\timestampable() ) ; The most powerful thing going on here is the 'type' section of the property function. You can have a vector of a vector of vectors containing a reference to whatever other database handle that you want. Or, you could have a vector of string, or an int field - or you could define your own type. If you have a one-to-one relationship, you'd put just a reference in there. It's easy and type-safe. The name is obviously the name of the property, 'default' is what it defaults to if it isn't given and 'required' is whether it can or can't be null. If you just pass this schema to the database\handle, it'll only accept records which match the schema. Schemas will also eventually be able to define behaviours, like in Propel - because that is a really cool concept. But the fact that I had to define cross reference tables in Propel ruined it for me; the ORM should be able to figure out if you need cross reference tables, and, if you do, it should create them for you. That's what I tried to code first and still use SQL, but it was pretty difficult (not impossible, mind) so I decided to persist data using regular files instead. I'm curious as to if anyone has implemented a flat file database similar to what I am doing, and whether or not performance suffers from multiple reads and writes? Obviously, I cache the data in the record (in a pretty fancy way, if I do say so myself) but each property is stored in a single file, eg. the "common_name" of a species is stored in it's own file. I've attached the current files for this database project, but it isn't finished yet. I hope you've enjoyed reading and maybe have a new perspectives on databases. They shouldn't have to be as difficult and confusing as they currently are. In a perfect world, you wouldn't have to know about cross referencing tables - your ORM should take care of that automatically. It's easier with a flat file database, but it wouldn't be impossible to write some convoluted code that converts the schema I presented above to a schema of a mySQL database - but ideally it should happen behind the scenes. Which would be the case if my site ever takes off, I start actually earning money and have reason to optimise the database. Until then, the flat file thing is much simpler and will suffice! database.zip my.zip
×

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.