Junction -- PHP 5 ORM

[Buyocat]

Over the summer I started a project which I would like to introduce to you.  <a href="http://junctionphp.com/">[/u</a>rl]Junction is a new persistance layer, much like <a href="http://propel.phpdb.org/trac/">Propel</a>, written in PHP 5 and based on the popular Java persistance layer <a href="http://www.hibernate.org/">Hibernate</a>.

 

A persistance layer is a little bit of software between the database and the application.  It maps data objects (with getters and setters) to database tables.  The goal is to automate basic query construction, decouple the application from the database, and allow for faster development.  With Junction you write a simple data object (the only requirement is that it have getters and setters) and a mapping file, following that you can start interacting with the database.

 

Following the open source mantra "release early, release often" I and my partners have chosen to release Junction.  It is our hope that you will find yourself immediately productive with it.  Over the course of the year we will be continuing development with a focus on several major features.  Please see our project <a href="http://junctionphp.com/">web site</a> for more information.

[dbillings]

Interesting.

[448191]

Looks like you guys have made some headway. Some questions:

 

• What do you do when an object's props don't directly map to table fields?
  
• How do you handle object structures?
  
• Do you put any requirements on the business objects (like getters and setters or public props)? Or;
  
• Do you have the business objects dependent on the DAO (the object uses a DAO to do CRUD operations)?
  
• Are there any example uses?
  
• Are there any facilities to generate metadata?
  
• Are there any safeguards to prevent RDBMS transaction/business transaction desync?
  

 

These are some of the questions I have asked about my own persistence layer, so I would love to get your view on them.

[Buyocat]

I'm not going to answer all of your questions here, but I'll try to answer the easier/important ones.

 

1) Properties which don't make directly to fields.

We call public getters and setters so there doesn't need to be an actual single property which corresponds to a table.  For instance, you could easily combine several properties in an object and return the result in some mapped getter.

 

2) Object structures?

If you mean collections (such as a collection of emails which are dependent on a user object) that isn't yet implemented.  That is the biggest feature which we are starting to look at now.

 

3) Data object requirements

It must have a public constructor which either takes no parameters or has default values.  For each property defined in the metadata file a public get and set property method is required.  That's it.

 

4) Please check out the code which has some sample uses included.  Also see the hosted code's wiki.

 

5) No tools exist to generate the metadata or data objects, but I've thought about it as a feature for the future (but it's lower priority).

 

6) Transactions are another big feature that we need to implement.

 

One thing on the business objects, Junction really is expecting a data object, not a business object.  By that I mean that the getting and setting is expected to return the value mostly as-is.  For instance, if you had a User object with a setPassword() which hashed the password, that would lead to problems.  In order to get a real business object you would need wrap around the data object.  I have a sample User business object which I can (and will) publish on the hosted wiki.