DataMgr 2.2 Beta 1
This is the first release of DataMgr wherein I can't take credit for any of the new features. Although this is a beta release, it should be pretty stable as I am running all of my live sites on it.
This is the first release of DataMgr wherein I can't take credit for any of the new features. Although this is a beta release, it should be pretty stable as I am running all of my live sites on it.
In my last post, I explained how I use an "all" field in combination with a many-to-many relationship to indicate that one record is related to any/all records in the related table (even if new records are added later). I have been using that technique for about three years now with very good results.
In fact, this worked so well for me that I added a feature into DataMgr 2.2 to handle it.
I have gotten several requests for Oracle support in DataMgr. Now it is finally here as part of DataMgr 2.2 Alpha 3.
With the release of the second Alpha of DataMgr 2.2 (What is DataMgr?), I am nearing feature completion for that version. What I would like to do now is add support for more databases. If you have wanted to take advantage of DataMgr, but you are using a database that isn't currently supported by DataMgr, then let me know.
If you can give me access to a database on your DBMS, that would be even better. I only need enough access to set up a datasource on my local box to point to a database running on your DBMS (with CREATE rights). I will do my best to add support for any relational database to which I can get access.
The second Alpha of DataMgr 2.2 is now available. In addition to the new features from DataMgr 2.2 Alpha 1, I have added three relation fields and one new method and removed a significant restriction for join tables. These changes should make it even easier to use DataMgr to develop your applications and keep your applications database agnostic.
It has been 6 months since DataMgr 2.1 was released. In that time I have been slowly improving my local copy of DataMgr. I now think that the improvements are ready for public trial. I am running several live sites on the build that I am making public.
We ran into a situation on a current project where we needed to return a column based on complicated logic. We needed to have a column that indicated if the value of an answer had changed since the user had originally answered the question. This logic was sufficiently complicated that even a custom relation field wouldn't do the job.
In situations where a layer of abstraction isn't able to handle the complexity required, it makes sense to break out of that layer of abstraction. That is why a ColdFusion programmer may sometimes (rarely) have to revert to Java. For DataMgr, this suggests writing SQL manually in situations like this.
In our case, however, we had already defined several relation fields that we needed to use and we didn't want to have to redefine them (or to ask DataMgr for the SQL for each relation field individually). We needed a way to add a field composed of complex SQL to our query without losing the benefit of our DataMgr relation fields.
A friend of mine called me yesterday with an interesting problem because he was unable to get some data for a record using DataMgr because it would require complicated logic. He didn't want to drop DataMgr because then he would have to write this logic in several places.