Download the PHP package eden/postgre without Composer
On this page you can find all versions of the php package eden/postgre. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package postgre
Short Description Eden PostGreSQL Search, Collection, Model ORM component
License MIT
Homepage http://eden-php.com
Informations about the package postgre
Eden PostGreSQL
- Install
- Introduction
- Basic Querying
- Data Manipulation
- Searching
- Model
- Collection
- Putting it Together
- Contributing
====
Install
composer install eden/postgre
====
Introduction
Eden's PostGreSQL objects are nothing short of spectacular! We take ORM in to a whole new level featuring search, collections and models, designed for novices and enthuisiasts alike. Before we go into those advanced topics, we should first go over the basic methods available. First off we need to add connection information to our database model shown in Figure 1
.
Figure 1. Database Connection Information
Simply put, we first instantiate the class giving the host, database name, user name and password in the figure above. There are no other requirements and you can start using methods immediately.
Note Eden's PostGreSQL object will only connect when the first query is made. This strategy is called lazy loading.
Basic Querying
On a very low level can call raw queries as in Figure 2.
Figure 2. Raw Query
$database->query('SELECT * FROM user'); // returns results of raw queries
Eden's PostGreSQL object uses PDO to communcate with your database. It's recommended you bind incoming variables contributed by the end user. Still on a low level, this can be acheived as in Figure 3
.
Figure 3. Raw Binding
The above figure sets $query
to a string with binded place holders :user_name
and :user_active
. $bind
has the actual values these placeholders and should be replaced with duing execution of the query. We encourage this method because binding values prevents database injections.
Note: Binded variables must start with a colon(:).
====
Data Manipulation
If you prefer the ORM way to save data Figure 4 provides several method examples on how to acheive this.
Figure 4. Data Manilpulation
Inserting data is pretty trivial. We included 2 ways to insert data. Like getRow(), there's no need to worry about binded data because Eden wil do this for you. Figure 4 shows the 2 kind of inserts mentioned.
Figure 4. Two ways to insert
So obviously insertRow()
should be used if you just want to insert one row. Inserting two or more rows at the same time, you should use insertRows()
. This method expects an array of arrays, or an array table.
Note: A common error found amongst programmers using Eden, is simply using
insertRows()
instead ofinsertRow()
.Note: Using models and collections, you don't really need to worry about this method because it's covered in the
save()
method in a collection or model object. We'll go over models and collections later in this section.
Updating is about as easy as inserting. There's only one method you need to know.
Figure 5. Updating
A common scenario is when you need to insert if a column value is not found and update if it is. We added an extra method called setRow()
to simply to save you some lines of redundancy.
Figure 6. Insert or update
Figure 6
basically says, in user table, if [email protected]
exists in the user_email
column, then update that row. If not then insert. Removing data is simple enough as well in Eden.
Figure 7. Remove
====
Searching
A better way to build complex queries is with using Eden's search object. An overview example can be found in Figure 8
.
Figure 8. PostGreSQL Search
In the figure above there's a few methods being powered with magic, but we'll just start going down the line. First off, to instantiate the search object you simply need to call search()
passing the name of the table as the argument. Secondly we call setColumns()
. This call is optional, but if used, can either accept an array of columns or an argument separated list of columns, ie. setColumns('user_id', 'user_name')
. Next, innerJoinOn()
is the new way we accept joins. There are eight methods dedicated to different kinds of joins.
Kinds of Join methods
No matter what methods you choose from above there are two arguments you need to add. The first argument is the name of the table you would like to join and the second one is the how they relate to each other.
The first magic powered method is called filterByUserName()
. There is no actual method called filterByUserName()
in the PostGreSQL class. Instead when this function is called it will parse out the name of the method and recognize that UserName is the name of a column and convert that into addFilter('user_name=%s', 'Chris')
as in Figure 8
.
addFilter()
generally accepts two arguments. The first argument is the filter clause. If you notice in our filter example in Figure 8
we use %s to delimit a binded value. You can have as many binded values per filter as you like. The following arguments need to include the binded values in order of when they occur in the filter clause.
The second magic powered mehod is called sortByUserId('ASC')
.There is no actual method called sortByUserId('ASC')
in the PostGreSQL class. Instead when this function is called it will parse out the name of the method and recognize that UserId is the name of a column and convert that into addSort('user_id', 'ASC')
as in Figure 8
.
There are three kinds of pagination methods also available
Pagination Methods
It's important if you are going to use setPage(1)
to call setRange(75)
first because the underlying function simply calculates the start index based on the range. Two other methods that are not covered by Figure 8
are the ability to group and to set the table to something else.
Figure 9. Other Useful methods
Getting Results
When your happy with your query you can retrieve the results in 3 ways as described in Figure 0.
Figure 10. Retrieving Results
Figure 10
shows three ways to get the results, the first way getTotal()
, will retrieve the total number and does not consider pagination elements. getRows()
will simply return a raw array. getCollection()
will return you an object with the results for further manipulation.
====
Collections
Collections do exactly the same thing as models except it manipulates multiple models instead. Collections can be iterable and access as arrays as well. Collections only hold model objects so if you wanted to use your own extended model, you would need to call setModel('Your_Model')
.
Figure 11. PostGreSQL Collections
Some other utility methods not covered by th above examples are date formating and copying from one column to another. Figure 12
, show how we would go about doing these things.
Figure 12. Utility methods
====
Models
In Eden, we managed to loosely define models which takes off the restrictiveness of a normal ORM and adds scalability as an end result. First off, what we did was define a generic, yet powerful model class that can be extended, but also can be used as is. Our model class is already powerful enough to solve for a lot of use cases, you might not need to extend it. We played around with the concept of "loosely defined" and here's what we came up with.
Figure 13. Database Model (Extends Array)
So model properties can be accesed by method, object or array. The preference we leave up to you. With our model, you can put extra key values in the object, even if it has nothing to do with the intended database table. When you call save()
, this is when you need to specify the table your saving to. This method is really powerful, in that it will first check to see what columns exist in the table then compares it with your model. It will only save columns that have the matching column name in your object. Lastly it will auto determine whether if we should insert or update that row.
A common example is when you have an array table that comprises of joined data. In Eden you can leave that array as is then call save()
for each table as in Figure 14
.
Figure 14. Two tables
Note: You can also save to different databases as in
save('post', $db2)
====
Putting it all together
So a common scenario would be retrieving data, manipulating the results and sending back to the database. Let's see with Eden's search, collection and model objects how we can acheive this.
Figure 15. The Coolest Thing Ever!
If you look at our MySQL or even our SQLite documentation. You'll realize that it's the same documentation as this one with the exception of small changes basic query section. We normalized all SQL database objects to use the exact same thing to reduce the learning curve.
====
Contributing to Eden
Contributions to Eden are following the Github work flow. Please read up before contributing.
Setting up your machine with the Eden repository and your fork
- Fork the repository
- Fire up your local terminal create a new branch from the
v4
branch of your fork with a branch name describing what your changes are. Possible branch name types:- bugfix
- feature
- improvement
- Make your changes. Always make sure to sign-off (-s) on all commits made (git commit -s -m "Commit message")
Making pull requests
- Please ensure to run
phpunit
before making a pull request. - Push your code to your remote forked version.
- Go back to your forked version on GitHub and submit a pull request.
- An Eden developer will review your code and merge it in when it has been classified as suitable.
All versions of postgre with dependencies
eden/core Version 4.*
eden/string Version 4.*
eden/array Version 4.*
eden/model Version 4.*
eden/collection Version 4.*
eden/sql Version 4.*