Navigate/Search

Archive for the 'ORM' Category

ORM… ERD – 2

Wednesday, October 7th, 2015

One thing I work on every day is creating a PHP entity class that inherits from a super class and the super class has all of the CRUD operations in it.  Not only do I want the super class to have all of the CRUD operations in it, I want it to notice when the table is missing and if it’s missing to create the missing table.  Also I want it to notice when a column is missing and if it’s missing to create a new column.  What I don’t want to do is ever create or add columns via SQL.

The reason I want this is because I am tired of having two references for my models.  I don’t like have to change two things when I add a new entity or a new attribute to an entity.  It’s seems like it’s impossible to keep SQL and PHP in sync and many times the errors can hang around for months before they present themselves.

I work in it every day for about 15 minutes.  It’s nice.  But my progress is very slow, so blogging about it would be very boring.  But I would like to have an ERD that describes this ORM functionality and how it works.

I want to build my ERD out of HTML and I want to build it in plunker.  I want to build it in plunker because plunker is AWESOME and because it’s easy to share and because it keeps track of history, but mostly because it’s AWESOME.

I haven’t actually put anything in my plunk yet… but I did create it…  Here’s the link http://plnkr.co/edit/Dththhd2cHPGibxNqcjN?p=preview.

ORMs… ERD

Thursday, October 1st, 2015

I have personal projects and my personal projects usually need back ends.  One thing I would love to be able to use is an ORM.  The main reason I would want to use an ORM is so I could describe classes in PHP and then they magically appear in my MySQL DB.  I find trying to keep my DB and PHP object synched to be frustrating.  Basically, I don’t like having two descriptions of the same thing.

I tried setting various PHP ORMs and I found the process to be confusing, have a lot of overhead, and required two descriptions again.  I think if the ORM requires it’s own set of descriptions then it defeats the purpose for me.  The whole point is that I can just add entities or attributes and it just work, not to replace SQL maintenance with PHP maintenance.

The truth is that a lot of people are making ORMs work.  So the problem is me… not them.  This isn’t the first time that I didn’t understand a technology.  Usually this means that I don’t understand something.

I don’t want to give up on ORMs because it’s going to happen.  So what I need to do is understand them better.  So what I am going to do is try to build my own ORM.

The first step is to build a system that allows me to create an entity and then when that entity tries to do an insert or select it automatically builds the table.  Also when I add an attribute to the entity and I try to do an insert it recognizes that the insert failed, recognizes that a column is missing and it adds the column, automatically.

The good thing about this is that a table will be described in that PHP class only.  There will not be two systems to maintain.  The SQL table is generated by the class for the classes purposes.

This is hard to explain, and this is definitely one of those times that an ERD is useful.  There are a lot of existing ERD software tools.  I don’t want to use and existing ERD software tool because I think it will be really fun to make my own in Plunker.  The plan is to use JSPlumb and either JQuery or AngularJS (HTML and CSS as well.)

So in my next ORM course I will take:

class Session extends Entity
{

public $id;
public $shape;

}

and put it in my home made plunker ERD or at least I will get all of the correct libraries loaded.

PHP Entity Super Class ORM… continued.

Monday, September 28th, 2015

ORMs do a lot of things and I think this is a very rare time.  One day ORMs won’t be needed anymore and then it will be difficult to understand their part of the process.  I like understanding things.  So I am going to build my own mini ORM.

The things I want to implement is the select, insert, delete, and update functionality within an Entities super class.

An entity is an object that has a bunch of attributes.  So a Fruit entity might have an attribute called shape.  Here is an example of a Fruit Entity in PHP.

 

class Session extends Entity
{

public $id;
public $shape;

}

This fruit entity has two attributes and ID and a shape.  Back in the J2EE days the Java folks came up with a standard.  That standard is to add getters and setters (it always cracks me up because for the longest time they called them mutators and accessors.)  They added getters and setters to all objects so that the objects would be able to communicate with each other.  It’s a good idea.

So next time I blog about ORMs I will add my getters and setters.

My end goal is to be able to call an insert method and that method attempts to insert the record (in a generic way) and if the table doesn’t exist it creates the table and if a column doesn’t exist it creates the column.  That’s the end goal.

 

 

PHP Entity Super Class ORM

Wednesday, September 23rd, 2015

I am currently working on a project.  What the project is doesn’t matter, but one thing I don’t want to worry about is trying to keep my PHP objects synchronized with my MySQL DB tables.

I am going to set up entity classes that match up to my tables.  I think this is pretty common.

I want my entity classes to inherit from an Entity super class.

I want my entity super class to have Object Relational Mapping code in it.  I want to map:

  1. Creating the entity table
  2. Inserting an entity record
  3. Selecting an entity record
  4. Deleting an entity record
  5. Updating an entity record
  6. Updating a table with new columns

What I want is to define an entity and have that entity extend the Entity class.  The entry will inherit an insertIntoDb function.  That function will write a record into the DB.   Then I want to define another entity and extend it with the Entity super class and it should just inherit insertIntoDb and just be able to insert.

What I don’t want to do is every have to look at the SQL, I don’t want to have create a table with a script or a tool.  I don’t want to have to tweak a table when I add an attribute.  I want to work in PHP only and the only SQL I deal with is in the Entity Super Class.

 

ORMs old idea rebranded as a new idea…

Friday, September 18th, 2015

I have a few friends that have been programming or around programming for 20+ years.

I am always amazed at how often we talk about how ideas were thought of a long time ago and they are being presented as new.

The ideas of an ORM has been around for a long time. I find it interesting that old concepts are very often presented as new concepts.

I think this re-presentation of old concepts as new concepts is unique to software development.

I think it has to do with how programmer minds work.

Larry Wilmore (An African American Comedian with a talk show on Comedy Central) does a very funny bit about why Nerd got so mad about a black storm trooper and why it has nothing to do with racism.

He says that nerds (I replace nerds with programmers like me) get very fixated with the definition of something and they don’t like definitions to change. He says something like if you give a nerd pancakes with nuts and maple syrup and call it pancakes and then a week later you give the same nerd pancakes with no nuts and maple syrup you better not call it pancakes. Pancakes will always have nuts in the nerds mind.

That’s why I think ORMs are being presented as a fairly new concept when it is a very old concept.

There have been excellent solutions that solve the problems that ORMs are trying to solve in the past.

One solution that got a lot of traction was NoSQL DBs. Working with NoSQL DBs is wonderful for JavaScript programmers. Everything just matches up. NoSQL DBs can be found in every Fortune 500 company. They are heavily used by CNN and all of the Digital Media companies.

Places that use NoSQL DBs don’t face a lot of problems that places that use Relational DBs face. Those are all facts.

The reality is that for some reason Relational DBs still exist and still thrive. I don’t really know why but my guess is that while NoSQL DBs work great for DBs that interact with web pages they don’t work great for other things that use DBs. Other things could be AI systems, control systems, graphics systems… see DBs are used for lots of things and web interfaces is just a teeny tiny sliver. NoSQL DBs are perfect for the teeny tiny sliver of things DBs are used for.

So I don’t know why, but Relational DBs are here to stay. They are really good for something.

The REST api specification has created a standard way for browsers to request data from servers. Since that standard has been widely adopted generic solutions for data delivery between DBs and UIs can be created.

These generic solutions are very natural in NoSQL environments. In some places you can just add an attribute to a JS Object on the browser and that object finds its way in the DB. It’s just natural. If the JS programmer shows the weather information to the user and decides that a new “Pollen Count” field is needed then they just add a new field onto the JS Object and send it up to the server. In most environments where they use Relational DBs that isn’t possible. It isn’t possible because someone needs to create a new column in the Relational DB.

While it’s great for the front-end developer to be able to willie nilly add attributes and it’s great for the user to be able to have pollen count show up without a big process it’s horrible for data analysis systems. Data analysis systems need a way to know what data is in the system.

I remember trying really hard to get some Java Developers to allow me to have a field that was just JSON text in the DB. In that field I held information like positions and colors. Basically, information that was UI specific in JSON format. We got it working but the Java Developers could not tolerate unknown data being submitted into their precious DB. It just went against their gut instincts. Eventually they pointed some kind of hibernate functionality at the JSON and any time I added new data it would not be stored. It wouldn’t be stored until they manually added the new column in the DB. It was nice because I could code up the front end and be done and then when they got around to creating the column it would just work.

Anyways, the columns need to be there for other systems that use the collected data. NoSQL DBs are freeking AWESOME for UI applications but they don’t work for anything that collects data for deep analysis.

ORMs have the potential to provide a bridge between Relational DBs and JSON front ends the way RESTful APIs have provided a bridge between Object Orientated server side classes and JavaScript Browsers.

Musing abouts ORMs

Sunday, September 13th, 2015

So this video https://www.youtube.com/watch?v=u3LhG8YxqSc is excellent. Lalit Bhatt does a great job explaining what ORMs are trying to accomplish.

At the very top of the list is Mapping an OO Object to a RMDB Table.  More specifically it’s mapping an OO Object’s attributes to a RMDB Table’s Columns.

I think the ability to map an Object’s attributes to a Table’s Columns opens to doors to two important features.  First, it makes it easy to auto create tables for new objects.  Second, it makes it easy to auto connect URL requests to retrieves.

I would make it possible to make your OO Object, deploy it to the server, and then hit a URL like www.mysite.com/ooname/ and that would just work.  A table would get built auto magically.  You could have automatic CRUD actions.

That would be awesome.

Awesome ORM Video

Wednesday, September 9th, 2015

This is an awesome video that explains the purpose of ORMs https://www.youtube.com/watch?v=u3LhG8YxqSc.

One day we will be able to write a single line of code (even say a single phrase) and an entire web application will exist.  It won’t be an application like what a web application is now, but it will be a fully functioning, useful web application.

The main barriers to this is that what a web application is hasn’t been fully defined and the the technology to build a full web application hasn’t been fully developed.

These two barriers are related.  They feed off of each other.  The technology gets a little more developed and then what the world wants gets a little more developed and as what the world wants gets more developed the technology gets more developed.

It’s like when you shop for a new car, you didn’t realize what you wanted until you saw what was available.  I didn’t know I like back up cameras on cars until I rode in a car with a back up camera.  Manufactures don’t know people want back up cameras until people start asking for back up cameras.  It’s a chicken and egg kind of thing.

I can imagine this line of code:

make orange sell buy trade forum chat

I can imagine that line of code resulting in a fully functioning web/mobile application that allows you to buy, sell, trade, discus, and chat oranges.

I think that technology is 90+ percent there.  With the latest front end frameworks and the latest back end frameworks we are almost there.  Here is a video that explains one of the few remaining gaps:

https://www.youtube.com/watch?v=u3LhG8YxqSc

 

ORMs… gnashing of teeth.

Saturday, September 5th, 2015

A few months back I decided that I wanted to learn about ORMs.  Since then I have seen dozens of videos and read dozens of articles about how bad ORMs are.

To me this is a fascinating situation.  It reminds me of a lot of classic arguments I have heard about technology in the past.  The first one I remember is when I was a pre-teen and people would argue over Main Frames vs. PCs.  The pro Main Frame people made excellent arguments about why PCs will never work.  I remember people arguing over Command Line vs. GUI… the Command Line people made excellent and truthful argument.   I remember people explaining why the concept a browser would never work… I remember people explaining why mobile will never work…

See ORMs are going to exist.  There is no way around that.  I mean I have literally been exposed to 100+ reasons why ORMs are bad.  Every single argument I have encountered has been correct.  EVERY one of them.

But it doesn’t matter.  It really doesn’t matter.  ORMs are trying to handle the interface between Objects and SQL.  Objects aren’t going any where for a very long time.  The object paradigm works very well for what it does.  SQL isn’t going any where for the same reasons.

Applications will need objects for the logic and SQL for the data storage/access.  Sure there are lots of alternative, but the:

SQL -> Objects -> GUI -> End User

stack is going to be around for a long time.  Right now the most awkward part of that stack is the interface between SQL and Objects.

If I had to guess most of the ORM functionality will eventually be absorbed into the language or frameworks.  So I bet once the ORMs figure out exactly how the interface should work it will become part of PHP, Java Web Apps, .Net…

 

ORMs…

Friday, August 28th, 2015

I keep trying to set up ORMs but they never work out for me.  My biggest problem is that they seem to fail silently.

I think ORMs are going to be important and they will work very well.  Right now they seem to cause more headaches than they solve.

The problem is that when it comes to storing and retrieving data nothing seems to work better than Relational Data Bases.  When it comes to programming software nothing seems to work better than Object Orientated Programming.

The interface between the two is always very hard to maintain.  A very common problem that ORMs sometimes claim to solve are changes between an object’s attributes and the column.

For example if you wanted to create a website about apples.  You might have a table called apples.  That table might have a column called seedsize.  The might also have an objects that has an attribute called seedsize.  You might decide to get rid of the attribute but it can be easy to forget to remove the column.

That’s the problem, with time the tables and the entities always get out of sync.  After a while there are columns that are never used.  Sooner later someone needs an entity called stemsize and they decide to use the abandoned seedsize column.

One major problem that needs to be solved is drift between OO entities and Tables.  It always happens and it always ends in tears.

ORMs have the potential to solve this drift problem.

Musings on ORMs

Tuesday, August 25th, 2015

When I am writing about ORM technology I am really writing about three technologies.

The first technology is Object Orientated Programming.  The second technology is Relational Databases.  The third technology is Object Relational Mapping.

  • Object orientated programing
  • Relational databases
  • Mapping

ORMs do hundreds of things and different frameworks do them in different ways. ORMs solve a lot of problems but they add a layer of complexity to your application.