earthit / storage
PHP Storage
Installs: 12 854
Dependents: 2
Suggesters: 0
Security: 0
Stars: 0
Watchers: 2
Forks: 0
Open Issues: 0
Requires
- php: >=8.1
- earthit/dbc: ^2.0.0
- earthit/php-common: ^2.0.1
Requires (Dev)
- doctrine/dbal: ^3.7.2
- earthit/php-project-utils: ^0.0.12
- earthit/schema: ^2.0.1
- phpunit/phpunit: ~10.5.5
- togos/tpfetcher: ^0.0.7
- dev-master
- 2.0.1
- 2.0.0
- 0.4.10
- 0.4.9
- 0.4.8
- 0.4.7
- 0.4.6
- 0.4.5
- 0.4.4
- 0.4.3
- 0.4.2
- 0.4.1
- 0.4.0
- 0.3.31
- 0.3.30-alpha2
- 0.3.30-alpha1
- 0.3.22
- 0.3.21
- 0.3.20
- 0.3.19
- 0.3.18
- 0.3.17
- 0.3.16
- 0.3.15
- 0.3.14
- 0.3.13
- 0.3.12
- 0.3.11
- 0.3.10
- 0.3.9
- 0.3.8
- 0.3.7
- 0.3.6
- 0.3.5
- 0.3.4
- 0.3.3
- 0.3.2
- 0.3.1
- 0.3.0
- 0.2.1
- 0.2.0
- 0.1.2
- 0.1.1
- 0.1.0
This package is auto-updated.
Last update: 2024-04-05 18:50:07 UTC
README
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.