smgladkovskiy / jelly
A flexible ORM for Kohana 3.1+
Installs: 51
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Watchers: 2
Forks: 34
Type:kohana-module
Requires
- kohana/core: ~3.3.3
- kohana/database: ~3.3.3
This package is not auto-updated.
Last update: 2024-12-19 19:58:08 UTC
README
Jelly is a nice little ORM for Kohana 3.1+. The project was originally started by Jonathan Geiger and co-developed by Paul Banks.
IMPORTANT
Critical to know:
- use the
3.x/master
branches for production as the3.x/develop
branches are subject to frequent and major changes - userguide is being updated
Requirements
Jelly requires the following Kohana versions per Git branch:
3.1/develop
and3.1/master
branches: Kohana 3.1.3+3.2/develop
and3.2/master
branches: Kohana 3.2+
Useful stuff:
Get involved in Jelly's developement
As Jelly has always been a community project it's development and future depends on people who are willing to put some time into it. The easiest way to contribute is to fork the project.
Remember:
- you can directly edit files on GitHub (look for the
Edit this file
button), there's no need to get familiar with Git if you don't want to - please follow the Kohana conventions for coding
- read the introduction to the unit tests in the guide and run them if you make changes to Jelly to minimalize the chances of introducing new bugs
- and thanks for helping Jelly become better!
Notable Features
-
Standard support for all of the common relationships — This includes
belongs_to
,has_many
, andmany_to_many
. Pretty much standard these days. -
Top-to-bottom table column aliasing – All references to database columns and tables are made via their aliased names and converted transparently, on the fly.
-
Active testing on MySQL and SQLite — All of the Jelly unit tests work 100% correctly on both MySQL, SQLite and PostgresSQL databases.
-
A built-in query builder — This features is a near direct port from Kohana's native ORM. I find its usage much simpler than Sprig's.
-
Extensible field architecture — All fields in a model are represented by a
Field_*
class, which can be easily overridden and created for custom needs. Additionally, fields can implement behaviors that let the model know it has special ways of doing things. -
No circular references — Fields are well-designed to prevent the infinite loop problem that sometimes plagues Sprig. It's even possible to have same-table child/parent references out of the box without intermediate models.