Database class

[n0nag0n]

This adds simplified functionality when accessing a database (cause PDO can sometimes be a little verbose)

[eydun]

Please do not add a PDO-class to the core. There are so many other options for storage than PDO-databases.

Mike built a most elegant and lean database-class (https://github.com/mikecao/sparrow), but never added it to the framework.

[sah-comp]

My recommendation for a ORM layer is RedbeanPHP.

[n0nag0n]

I just wanted to make sure that you guys saw what the actual code was. I wasn't adding an ORM, or a Mapper, or a flavor of that. Sparrow is cool, so is Redbean (heck even Propel would fit in the Flight theme :laughing: )

The purpose of this project is that it should have a very, very simple way to setup some routes, and pass back data for an API. When I have setup an API, the vast majority of them interact with a database, and typically that database is MySQL/MariaDB. I could make an argument that I should merge in some kind of ORM type thing in here, but I'm trying to keep it the core very simple.

In my experience, I've helped train a lot of developers at my company but I've also been lucky enough to help new coders find their way into PHP. Bless their hearts, but the PHP world can be really overwhelming to them. I remember starting out and I was following tutorials online and I had no idea what they were doing or why they even worked. Now that I'm older I understand better and I see things through their eyes, and it's why I created a simple wrapper for PDO so that querying a database was easier. They don't need to know what a prepared statement is, what a PDOStatement does and why it's different from PDO. All they know is that their boss just came to them with a SQL query and said, "make an API for that" and they are stumbling around google trying to figure out how to do that, or they might have a project with Flight already in it and they just need to know how to translate an SQL query into a JSON response.

So that's why I made the PdoWrapper class, so it's easy for new developers to just get something done that doesn't fly way over their heads.

[eydun]

You are the boss. But I personally never use pdo-driven connections for storage. Static storage such as yaml/markdown or even json are prefered by many.

What are you gonna reply, when users come with requests for a more complete pdo-implementation?

How about placing the pdo-class in the new and nice skeleton project?

[n0nag0n]

I do have a skeleton project I just got up today at flightphp/skeleton. I guess I'm curious about some API examples you have. So the API's you interact from a Flight project, are all static files? I've seen examples here and there, but the vast majority of API's I've seen use a database. And all API's I've ever worked with pulled or pushed data into a database of some kind (MySQL, MariaDB, Postgres, Mongo, Redis, etc). Could you show a simple example of what you work with cause maybe there's a case to include something in the framework for your use case (if it's more common than I thought)

[eydun]

I have used many frameworks throughout the years, but mostly F3 and Nette. Currently transitioning towards CodeIgniter (avoiding Laravel by all means).

When building simple content sites, we mostly use some static storage, mostly markdown. For API's there is almost always some database involved. For database-access we always use dibiphp (never PDO-driver).

Have not used FlightPHP for many years, because it was not maintained. But was hoping to start using again now for smaller sites. I like the idea to use a framework such as Flight as a core, and then glue it with other preferred projects, such as twig for view, dibiphp for db, tracy for debugging, etc.

[cdsaenz]

Here a long time user of Codeigniter (3 for a long time, now 4). I am really fine with its ActiveRecord class, don't need more, an ORM seems to much hassle, I prefer raw SQL in complex queries. Here I learned about Sparrow, which looks quite similar to ActiveRecord. I'll probably use it, for now Flight is in.. Test Flight for me :) but I love it. Added Twig (which seems a standard for many) or it could be LiquidPHP. The idea is always small sites (which there are a LOT of) and a small core to work on with "modules".

[n0nag0n]

Have not used FlightPHP for many years, because it was not maintained. But was hoping to start using again now for smaller sites. I like the idea to use a framework such as Flight as a core, and then glue it with other preferred projects, such as twig for view, dibiphp for db, tracy for debugging, etc.

This is my goal as well. For me, Latte is my preferred templating language as it "feels" closer to PHP than Twig does. I'm also going to be creating a Tracy package for Flight similar to my F3 package for Tracy that I built to have better insight into what Flight is doing and how it was executed.

I have lots of ideas for Flight and the ability to extend it in easy ways, but leaving the core, the core.

Thanks for the feedback guys. I think I'll leave the PdoWrapper I have in the core for now, but I think on the main readme, there needs to be some good recommendations for the "missing" pieces of flight, like a templating system, session handlers, activerecord/orm/mapper etc.