Announcing DataMgr 2.1
When I released the full version of DataMgr 2.0, it was partly because it was stable and partly because I had some ideas for 2.1 and I knew I needed to finish up 2.0 before I started such major changes (2.0 had already been through 4 release candidate versions, after all).
This time is different. DataMgr 2.1 is the fulfillment of the vision that I had for 2.0 (no knock to that version, of course).
What is DataMgr?
Before I get into what is new and better about 2.1, a review is in order on what DataMgr is. I find that it is often much more difficult for the author of anything to concisely explain a thing than for anyone else, but I will do my best.
More than anything else, DataMgr is meant to manage CRUD (that is, Create Read Update Delete). Everything else that it does is an extension of this.
Most solutions for CRUD work on one of two principals:
- SQL Generation
Both of these have some code that writes other code and saves files. ORM requires an OO approach. If you are using a full OO approach, this is great. If not, it is a lot of extra work to get any benefit.
SQL Generation means that although you don't have to write the SQL, you still have a bunch of SQL in your code. This isn't a bad thing, but it can still leave you with much of the tedium of managing a bunch of SQL code in your application.
DataMgr takes a path of database abstraction. It doesn't generate any code or save any files. If you want to update a record (in your "products" table, say) from a form, just make sure that the form field names match the table field names and that you include the primary key value and then call updateRecord():
The DataMgr page includes links to several blog entries on using DataMgr as well as full documentations (19 pages of it).
DataMgr runs on ColdFusion MX 6.1 or better and currently supports the following databases:
- MS Access
- SQL Server
If you have another database that you would like to see supported, let me know.
What's New in DataMgr?
If you aren't familiar with DataMgr, I suggest checking out what DataMgr already has before looking here. For those of you familiar with DataMgr, here is what version 2.1 adds to the mix:
- Cascading Relation Fields
- Custom Relation Fields
- Optional "sort-field" attribute for "list" relation field to dictate order of list
- Optional "delimiter" attribute for "list" relation field
- DataMgr throws error for more than one "Increment" field in one table
- Report datasource name in loadXML() error
- Optional bidirectional self-relational many-to-many-relationships
- Optional "advsql" argument in getRecords
I have actually discussed most of these features in the DataMgr 2.1 Alpha announcement. I plan to cover them in more detail in future entries here.
The general theme of 2.1 is that it provides more power and flexibility (without reducing ease of use).
How to Upgrade
Every new version of DataMgr, including 2.1, is fully backward-compatible. Just back-up your existing DataMgr files (just to be safe) and copy the ones over them. Then you can reload your components and you are done with the upgrade.
All existing code running on previous versions of DataMgr will continue to work on DataMgr 2.1.
How to Get DataMgr
DataMgr is open source and free for any use. You can go to the DataMgr page on my site to find out more about DataMgr and you can download DataMgr from RIAForge.
If you have any trouble, feel free to report it on RIAForge or let me know directly.
Thanks in advance.
Certainly you can. You can use my contact form:
Or you can send an email to me (using my first name at the domain name of the contact form).
dataMgr saves a value of 5 in the corrisponding field.
my table metadata are ok: i've tried to hand code the insert statement and the saved value is right.
is this a bug or a mistake (from me of course)?
Can you use my contact form and send me the XML for the table - just use DataMgr.getXml('tablename')?
Then I can take a look and try to help determine where the problem is.