Add database connector [SERINA-10]
Add mapper [SERINA-10]

Move database connection as a reference inside the base mapper. Should
that be a singleton? I can't decide.
Add automatic model hydration [SERINA-10]

This automatically maps properties to db columns as specified in
properties()
User PropertyDefinition class [SERINA-10]

This formalises the args required to specify a model property
definition.
Alias addProperty to use PropertyDefinition [SERINA-10]

This makes using addProperty() a bit quicker as you don't have to type
so much stuff
Add join [SERINA-10]
Add sql dumps [SERINA-10]
Spawn UserMapper, add dynamic sql select [SERINA-10]

This furthers Mapper production as it allows you to dynamically
construct exact column selection, based on model/mapper property
definitions. This should allow joins further on.
Move hydration responsibilities into its own class [SERINA-10]
Move selection method out of constructor [SERINA-10]

This allows it to be compatible with mapper classes
Add GenderMapper [SERINA-10]

This is obviously used in conjunction with the current UserMapper
Refine syntax [SERINA-10]
Add AddressMapper [SERINA-10]
Add StateMapper [SERINA-10]
Add CountryMapper() [SERINA-10]
Remove mobile, update generator [SERINA-10]

Phone is now a collection of provided phone numbers as a person may own
multiple mobile phones.
Add PhoneMapper() [SERINA-10]

Now we enter a stage in mapping where there are duplicate columns until
the element last joined (in this case, phones)

Users, Addresses etc are duped because when Phone is joined, there are
multiple phones per user.

Mappers will have to ignore dupe data like that...
Add mapper infrastructure for joins [SERINA-10]

This should allow for dynamic mapping and object graph construction
without having to manufacture it all manually, the long way.
Start migrating stuff to a Query class [SERINA-10]

This allows a relation object graph to be built, to see which objects
(once hydrated) belong to which other object. Previously attempted this
directly with the mappers, but since mappers are a distributed system,
there was no convenient way to manufacture this object graph. A way to
arbitrarily get the right references etc was needed without getting
messy. Thus, class Query

This should be able to arbitrarily reach out to various mapper classes
based on the select() definition by concatting the model name with
Mapper.
Use select() to spawn a part of the overall QueryString [SERINA-10]

This Query class will allow us to build a querystring to execute (as
normal) as well as remember the relations between the various models
included in the query, thus allowing us to construct a useful object
graph.