DBAPI additions for table metadata

I added a couple of DBAPI functions to one of my projects I’m working on. It includes a class I’ve created which uses table metadata (and arrays that define the form elements) to generate and process inserts/updates from dynamic forms. It also makes use of chunks as templates you can override for outputting each form element. But in order to properly validate and process the forms, I needed access to table metadata so I added the following property and methods:


dataTypes is an array of array’s containing all the database types that should be treated as numeric, string, or datetime values. A simple lookup into this array after retrieving the actual database column type helps determine how to validate and process the value for specific form elements within SQL inserts or updates.

Thoughts, comments, alternative approaches or ideas (before I decide to add these methods/fields)?

Eventually, I think we could use this infrastructure along with some additional enhancements to create a complete object persistence framework and class factory for user-defined entities (e.g. generate classes from data tables and/or generate data tables from classes, managing all persistence operations on these custom objects via easy-to-use base persistence class methods).

Ummm... any chance you could rephrase that in plain old English without the tech terms.

If I understand it correctly, it could for instance dynamically create all the tables/columns/rows needed for a custom application on the fly, correct? If that’s the case then yesterday would be a pretty good time to start working on this.

Other real-world example of how it’s done now vs how it would be done with the new class and metadata?

Quote from: rthrash at Aug 24, 2005, 12:03 PM

Ummm... any chance you could rephrase that in plain old English without the tech terms.

Well, I thought this was the core development forum ;-). Ok, I’m talking about introspection on database tables, so you can get a list of columns and details from core or custom tables and then determine how to process values for these columns (as strings, numeric, or datetime values). That’s what these new DBAPI features allow.

With this I created a form helper class which uses the introspection to automatically create INSERT/UPDATE statements from $_POST variables (and could also be used to validate input values, or even auto generate forms based directly on a database table; I’m currently defining the forms manually and just using the new DBAPI methods to help in processing the INSERT/UPDATE activity).

Quote from: rthrash at Aug 24, 2005, 12:03 PM

If I understand it correctly, it could for instance dynamically create all the tables/columns/rows needed for a custom application on the fly, correct? If that’s the case then yesterday would be a pretty good time to start working on this.

And yes, it can be used in reverse (with some refactoring/additional features) to create custom tables as needed at runtime. I envision a manager module which allows end users to generate a class and corresponding db table with appropriate properties and behaviors (or vica versa, have it create classes from a data table). These definitions could be used in any number of ways, from easy form creation and processing, to attaching plugins to conditions or rules defined in the object class (e.g. extending the event model to allow creation of custom events for the objects).

It’s the beginnings of an object-relational mapping tool that can be utilized to allow easy, wizard-based creation of everything from simple dynamic forms to complex web applications with custom workflow capabilities.

Quote from: rthrash at Aug 24, 2005, 12:03 PM

Other real-world example of how it’s done now vs how it would be done with the new class and metadata?

It’s not really done now, without hooking into an external object-relational framework. Adding this capability would simply move us one step closer to supporting any number of database/persistence engines; if we converted the core data objects/tables to this system it would bring some portability to custom applications that interact with data using the framework, by isolating the business logic from the persistence mechanisms. E.G. Develop on MySQL, and then deploy to Oracle with no code changes.

I’m sure this will take more clarification, but I hope that helps a little. Still too many tech terms, but...

Develop on MySQL, and then deploy to Oracle with no code changes.

WOW !!!!

No more comments, sorry, actually you know

Sounds great

I can understand the power and flexibilty of what opengeek descirbed.

Many years ago I have written an application in FoxPro to scan entire database and compare to a know structure whether it is current or new structure to be enhanced then I will go through the structures one by modified to match what I want it to be either remove it, changes or new additions.

Using this application my company can upgrade any database for any custom any time any where without fear of loosing data in the database. The application can either run locally or remote across the network.

So as the result the upgrade processes used to take a few days to a few weeks to do the upgrade for a customer but now with the help of my application my company can upgrade a customer remotely in a few minute per machine. It was a great time saver for us and for our customer and save our support staff many trip to the custom site.

It took me many months to develop this application but once it is in production it work solid!

This thread really bring back my memory on this fun and challenging project!

wooooo,

understanding check :::

Would this mean that this could be used as a "ultra-mini" phpadmin?
Here’s what I’m looking at (just tell me if I’m plain out of the ball park or not ...)

here’s what I want:
mini-phpadmin

By which I mean: custom product table (hehe, shopping cart)
so I’d have a table for products

I figure there are about 100-200 major different types of stores so ... if I go ahead and hard code a cart table (ie, oscommerce) I’d be limiting myself to major attributes only; id, quantity, model ... oh sheeet, that probably would already alienate a bunch of shops already.... see my dilema?

So, if this class could go with a system where the end shop owner could plugin their own column names they could develop their own system without having to hack any core code.

Would this work with what is being talked about here?

I think it’s what we’re talking about indeed Carsten. And I think we can count on you to lobby hard for it.

yummy

What ever happened with this?