Thoughts concerning PDO?

[TTx5]

I went through the SourceForge archives looking for discussions about moving to PDO and didn't find a lot, but I wanted to see if there were any strong feelings about it. I know PHP & MySQL have a long history, but since PDO would open the door to many other Database backends, is there a reason (beyond the coding effort) that it was never adopted in the project?

Is there perhaps some special MySQLi functionality in use, or is it expected that a lot of the queries were not written in standard SQL?

I'm interested in the project, but I have different preferences on DB, and I want to understand the past dev choices & future roadmap.

Thanks,
Travis-

[timschofield]

Hi Travis, what DB do you have in mind? There shouldn't be special MySQLi queries, but I wouldn't like to guarantee it. I have always wanted to include postgres in webERP (there is a start that has been made) but just don't have the time ATM Thanks Tim

…

On Tue, 11 Feb 2025 at 14:55, TTx5 ***@***.***> wrote: I went through the SourceForge archives looking for discussions about moving to PDO and didn't find a lot, but I wanted to see if there were any strong feelings about it. I know PHP & MySQL have a long history, but since PDO would open the door to many other Database backends, is there a reason *(beyond the coding effort)* that it was never adopted in the project? Is there perhaps some special MySQLi functionality in use, or is it expected that a lot of the queries were not written in standard SQL? I'm interested in the project, but I have different preferences on DB, and I want to understand the past dev choices & future roadmap. Thanks, Travis- — Reply to this email directly, view it on GitHub <#355>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL6LHWHOZTUDWVTVT5KYD2PIFMVAVCNFSM6AAAAABW5IDGBCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHE2DMOJYGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- www.weberp.org <http://www.weberpafrica.com> @TimSchofield2 Blog: https://kwamoja.home.blog/

[bcinteractive]

Just from my reading experience - PDO seems to be suggested often. I am used to the way webERP is using mysqli. Converting webERP or providing PDO is a nice feature.

[timschofield]

It has been discussed before. My view (and I know it's not universally popular) has always been that it goes against one of the fundamental principles of webERP which is to make the code easily readable to people who wish to use and adapt webERP but do not come from a background in coding. This goes right back to when Phil started the project and I am yet to be convinced that the advantages of adopting PDO are enough to warrant ditching this principle. Thanks Tim

…

On Fri, 14 Feb 2025 at 05:17, bcinteractive ***@***.***> wrote: Just from my reading experience - PDO seems to be suggested often. I am used to the way webERP is using mysqli. Converting webERP or providing PDO is a nice feature. — Reply to this email directly, view it on GitHub <#355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL6LAPR73LZOIX5XVEXFL2PV35BAVCNFSM6AAAAABW5IDGBCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMJZGYYDIMI> . You are receiving this because you commented.Message ID: ***@***.***>

-- www.weberp.org <http://www.weberpafrica.com> @TimSchofield2 Blog: https://kwamoja.home.blog/

[andrewcouling]

I believe Travis's enquiry offers valuable insights into current web technology trends. While I agree that we should adhere to the founding principles of webERP and maintain easily understandable code (which is crucial for novices like me), it's also important to stay relevant in the open-source space by providing features that will drive the adoption of webERP.

@TTx5 , do you have an estimate of the coding effort required to implement PDO in webERP?
From my research, it appears that PDO can connect with around 12 different database types, including those currently supported by webERP. If PDO requires a single PHP script to connect to databases, similar to ConnectDB_mysqli.inc, this could reduce the number of scripts and code we need to maintain. We would, of course, add plenty of comments to the PDO code to ensure it remains easy to understand.

@TTx5 , if we reach a consensus to tentatively explore PDO implementation, would you be willing to support its development?

Regardless, this should be a post v5.0 initiative. We must stay focused on v5.

[TTx5]

Andrew, I'll start with some disclaimers:
I've only been evaluating whether it's feasible for us to use at my employer, or one of our subsidiaries (or whether we could make it feasible...) and I haven't been involved with the project - so I admittedly only have a rudimentary understanding of the structure at the moment. However, I believe most of the once-MySQL and now MySQLi code was abstracted away into the ConnectDB include.

I manage a small IT dept at a manufacturer, so I don't write code full time, and my PHP skills are beyond rusty- but I could take on some serious effort on this if it was leading my employer in the right direction.

I believe the older MySQL code was abstracted away because it took quite a few lines of code for each DB call. My understanding is that MySQLi improved that quite a bit, and may be similar to PDO calls now. So my guess would be be that there would be two potential ways to move forward:

1. If all the rest of the system uses calls into ConnectDB, just converting it to use PDO internally would get to the finish line, keeping the custom DB abstraction layer.
2. If the structure of the ConnectDB calls are very similar to that of the PDO calls (or if there was a consensus that eliminating the custom DB abstraction layer made the codebase more approachable, or whatever)- then the code in the rest of the system could be moved to PDO and eliminate the other include(s). That would be much more effort, but most of it would be repetitive/boilerplate code replacement.

[timschofield]

Hi Travis, I was one of the very early developers of webERP and have been involved for 20 years, so I can offer some historical context to this discussion.
The original idea was that we would provide an interface to multiple DBMSs via ConnectDB_mysql.inc ConnectDB_postgres.inc etc, and that we would avoid any non standard SQL in the code so that all SQL statements would always work no matter what DBMS was chosen. I did in fact try to get ConnectDB_postgres.inc to work, but because of my lack of knowledge, and lack of time to get that knowledge, it never worked. Also over time, some mysql specific SQL has crept in.
Both Phil and I are accountants, with no formal training in writing code. Enthusiastic hobbyists is probably the correct term. As such one of the founding principles has always been that the code should be easy for people like us to pick up and understand. In fact I was sending patches to Phil within a couple of hours of downloading the code :). We have always understood that this style is not always to the taste of people with more coding education than us, but we have always tried to stand firm on this principle.
So, there was a discussion on the old (and since deleted) forum on using PDO about 10 years ago now. It was decided after a heated discussion not to go ahead as it would have involved changing every script, and it was considered it made the code less readable.
However, if it were possible to transition to using PDO via the ConnectDB files (which is one option you seem to be indicating) then I would be happy to do this - after v5.0. There is still the issue of non standard SQL in the code, but I think changing this should really be done anyway.

Thanks
Tim

[TTx5]

Tim,
Thanks for filling in the back story- I do understand the founding principles you're referring to, and appreciate fully the basis behind those. I have no interest in pushing unwanted change... I can always just make whatever changes I need and not share them- My reasoning for bringing up the subject was to gauge interest, and to determine the status, if someone was actively working towards this already. :)

Travis-

[timschofield]

Hi Travis, thanks very much for your reply. As I said, it has always been an ambition of the project to support other databases, so if a way can be found to integrate PDO while sticking with our principles, nobody would be happier than me!

I would be happy to work with you on option 1 on your reply yesterday. I do want to get v5.0 over the line first though

Tim.

[timschofield]

I think that perhaps a way forward would be to take one of the simpler scripts, so that we can compare what it would like altered for PDO with how it looks now, so we can compare it for readability. Tim

…

On Fri, 14 Feb 2025 at 23:02, Andrew Couling ***@***.***> wrote: I believe Travis's enquiry offers valuable insights into current web technology trends. While I agree that we should adhere to the founding principles of webERP and maintain easily understandable code (which is crucial for novices like me), it's also important to stay relevant in the open-source space by providing features that will drive the adoption of webERP. @TTx5 <https://github.com/TTx5> , do you have an estimate of the coding effort required to implement PDO in webERP? From my research, it appears that PDO can connect with around 12 different database types, including those currently supported by webERP. If PDO requires a single PHP script to connect to databases, similar to ConnectDB_mysqli.inc, this could reduce the number of scripts and code we need to maintain. We would, of course, add plenty of comments to the PDO code to ensure it remains easy to understand. @TTx5 <https://github.com/TTx5> , if we reach a consensus to tentatively explore PDO implementation, would you be willing to support its development? Regardless, this should be a post v5.0 initiative. We must stay focused on v5. — Reply to this email directly, view it on GitHub <#355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAL6LC7FGZ4INWTP4J3SO32PZYZ7AVCNFSM6AAAAABW5IDGBCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRQGYZDOOI> . You are receiving this because you commented.Message ID: ***@***.***>

-- www.weberp.org <http://www.weberpafrica.com> @TimSchofield2 Blog: https://kwamoja.home.blog/

[TTx5]

That sounds like a reasonable plan to me.