Download the PHP package earthit/storage without Composer
On this page you can find all versions of the php package earthit/storage. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package storage
PHP Storage
A data access layer.
Goals:
-
Glean schema information from a EarthIT_Schema object.
-
Provide a consistent API for fetching from and storing into a database or databases.
-
Objects passed in and out are in 'schema form'; transformations to database form are done by the storage layer.
- Allow custom storage layers to do additional transformations.
Design principles:
-
Excplicitly state which representations of objects are used where, rather than relying on coincidental similarities between them.
- e.g. a function that takes an object should indicate in its documentation which form that object should be in.
-
Data is separate from the plumbing. Data objects are just arrays (or, conceivably, scalar values. But usually arrays).
-
Backend agnostic. May be RDB. May be something else entirely.
-
Allow efficient access to collections of objects of the same type.
- Functions should generally be written to operate on collections to amortize overhead costs.
-
Should be able to use query generation and object conversion utilities independently.
- Punting on multi-table joins for now. Easier to just do the joins in PHP by querying by sets of IDs, especially when links cross database boundaries.
Object representations
-
DB-internal form: actual bits stored in the database. Our PHP code never sees these.
-
DB-external form:
Values from the database with minimal transformations applied to make them representable in PHP. e.g.
- BIGINTs are represented as strings
- GEOMETRY values are represented as GeoJSON strings
Keys correspond exactly to column names.
-
Schema form: form as described in schema.txt.
JSON fields are decoded
keys are 'plain english' field names.
-
JSO form:
Standard form for JSON REST services. Values will usually be the same as those in schema form, but keys will be 'camelCase' instead of 'plain english'.
- "JSO" is not a typo. Objects in this form are the objects that would be JSON-encoded without JSON encoding yet applied, hence no 'N'.
- 'id' field is added to objects that have composite keys.
- Transforming to/from this form is out of the scope of this library.
