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).
On most web sites, I typically allow my clients to edit the content on the pages of the site. I also generally have email messages sent out in response to certain events.
For example, I might have an email that tells a user that we have received their application. This is generally sent out by the component that handles processing the application (in my case, usually using Mailer.cfc).
Much like in the case of content on their site, the client will often want to change the content of the email. It isn't as easy to have them do this, however, as the component needs to be aware of the email message and having the component reference a primary key of data in a database seems like bad form (violating encapsulation - after all the key may be different on the dev database than the live one).
Still, changing the content of the email myself isn't challenging work and isn't the best use of my clients money. As such, I needed a better solution.
The second (and hopefully final) beta of DataMgr 2.1 is ready for download.
This release has one new feature - the getVersion() method which will return a string indicating the version of DataMgr (so, "DataMgr 2.1 Beta 2" for this release).
Other than that, this release fixes a few bugs (including ones which will help add Derby support soon).
I think I haven't explained the new "Cascading Relation Fields" feature well yet, so I thought that I would use an example from a recent discussion I had about DataMgr.
When I read Ben Forta's announcement (and follow up) that ColdFusion 8 would ship with support for the Derby database, my first thought was "I should add support for that in DataMgr". This proved to be a good introduction to Derby.
I decided that I would get my local copy of my demonstration site running on Derby.
DataMgr 2.1 is now in beta. Aside from fixing one or two small bugs, nothing has changed from the Alpha release.
It take this as a pretty good sign as I changed a fair bit of the inner workings of DataMgr in order to achieve the new features of 2.1. It has been running on several live sites for a few days now without any problems.
I got a call yesterday from a friend of mine who is just starting to use DataMgr. He asked me how to use the QuerySim feature of DataMgr which made me realize that I had never written a good explanation of how to use it.
In most of our interactions between code and database, one dictates the other. If we are working with a legacy database, then the structure of the database will dictate how we write our code. If we are proceeding from a visual prototype, then our database follows from our design.
I realize that DataMgr 2.0 hasn't been out long, but I thought of a few features that I wanted near the end of the 2.0 development cycle. Since they required a fair bit of extra effort, I thought it best to hold them over for a "2.1" release.
Although I have been given some good ideas for future versions of DataMgr, the 2.1 version will probably be the last major release for at least a few months - I have some other projects that I want to give some attention.
DataMgr 2.1 is still in alpha, so the feature set may change (unstable features may be removed), but the features in the alpha are:
Last night I was able to present to the Online ColdFusion Meetup Group (if you haven't already, you should really check it out). I was a bit nervous, but I think it went pretty well overall.
I was presenting on DataMgr - a non-ORM data access layer (I always have a rough time giving a simple answer to "What is DataMgr?").
Some prominent ColdFusion programmers attended, which was a bit intimidating. I am curious now to see what people think of it now that they have seen it.
Certainly, anyone already using an ORM will be happy with that approach. For anyone who doesn't want to use an ORM (or who would like to create their own) hopefully DataMgr will be a good option.
I did forget to cover a few things that I meant to mention, but I suppose that is to be expected. Among them:
Here are some links from the presentation:
Thanks to Charlie and Ray for allowing me to speak to the group. It was a lot of fun!
Reviews:
I am working on DataMgr 2.1 and I have run into an issue with which I would love some advice. This doesn't require any knowledge of DataMgr itself.
This problem deals with many-to-many joins. For example a user could be a member of multiple groups and each group could have multiple users as members. This would generally be handled by a join table. For example, if users were stored in a "users" table and groups were stored in a groups table, the relationships between them might be stored in a "users2groups" table.
A relationship could also be self-referential. For example, products (represented with a "products" table) could reference related products (also in the products) table. This could also be handled with a join table.
The question I have is how to handle the bidirectional quality of these relationships.
In the case of users and groups, if a user is a member of the group then the group has the user as a member (yes, I realize that was tautologous). This is because a row exists in "users2groups" to represent the relationship between the two. More specifically, this row represents a bidirectional relationship between the two tables.
In the case of a self-referential table, however, this is not necessarily the case. Each row of the join table only represents a unidirectional relationship between the product and the related product.
So, if "products2relatedproducts" had the fields "product_id" and "relatedproduct_id" (each referencing the "product_id" field of the "products" table) then the row would indicate that one-way relationship. If product "A" had product "B" as a related product in this table, then the row would not show that "B" had "A" as a related product.
This scenario is inconsistent with how many-to-many relationships generally work.
So, finally for the question:
If such a relationship is managed through DataMgr, would it make sense (and be helpful) if DataMgr enforces the bidirectional nature of the relationship (making self-referential relationships more consistent with other relationships)? Would it be better to have this as an option?
Thanks in advance for any and all thoughts.
