DataMgr 2.5 Beta 3

Happy Ground Hog's Day! It looks like I have completely stopped releasing open source project lately. Hopefully I can get back on track.

More than a year after releasing DataMgr 2.5 Beta 2, I am finally releasing DataMgr 2.5 Beta 3. So, what took so long? Neglect, basically. I have just been busy with other things.

Even so, I think this is a very good release and should be a close match for the final release of version 2.5.

(What is DataMgr?)

So, what is new in DataMgr 2.5 Beta 3 (since Beta 2)?

  • "hasRecords" method for efficient checking of existence of records matching criteria.
  • Ability to migrate fields - moving old data to new field names. Handy for renaming fields or easy migration from many-to-one relationship to a many-to-many one.
  • SQL Server: Added support for varchar(max) (and made it the default for LONGVARCHAR).
  • Ability to check for table existence.
  • Documentation for "ftable" attribute.
  • A few bug fixes.

Feel free to download DataMgr 2.5 Beta 3 (zip) or use the repository for the Bleeding Edge Release. For the latest full release, use the DataMgr RIAForge page. DataMgr is open source and free for any use.

Related Blog Entries

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Glad to see the VARCHAR(max) issue made this release.

Steve, I've got a quick question that maybe you can help me with, mostly because I'm too busy to go through all of the docs right now myself. Is there a way to use saveRecord without knowing the Primary Key value. Let me explain: I have a Users table with a Auto-incrementing primary key. In that table, there is an email address field. Obviously, I don't want 2 users with the same email address. This is a Facebook integrated site, so in some cases users register directly with me, and in some cases, they use Facebook Connect. In very rare cases, but plausible ones, I may have a user that registered with me, then tries to do it a second time through FB Connect. In that scenario, I'll know their email address, but not their userID. Normally, I'd just save the information to the table by using a WHERE clause on the email address, but I'm not sure I can do that with saveRecord(). So, for now, I do a quick lookup to get it if it exists. The long and short of it is, is there a shortcut to saving records to the DB using something other than the primary key as my de facto WHERE clause?

Thanks, Sean
# Posted By Sean Ford | 2/9/12 5:35 PM

Two answers:

1) Right now, you would have to do a lookup. I have thought about adding an attribute to a field definition to enforce that it should have a unique value for each record. If I did that, then I guess I could add another to indicate that it new records should do an update if they enter an existing value for a new record. I'll have to ponder.

2) The saveRecord method actually does check for existing records by more than just the primary key. If every queryable field (not BLOB or CLOB) in the data set matches an existing record, then saveRecord will perform an update instead of a delete - even if no primary key value is present.

For this to work, however, the data argument can't be sent any data that doesn't match the existing record. If that is the case, though, you can just use saveRecord() without any worry.

Hope that helps,

# Posted By Steve Bryant | 2/10/12 1:49 PM
ok, that's what I thought. on first glance, I would think you might be able to port some of your code from the getRecords() function. I would think the data and/or filters arguments could be used (filters would allow for more flexibility). If the filters attribute existed, use that, if not, default to the current method. (would keep it backward compatible as well).

Question: You state: "If every queryable field (not BLOB or CLOB) in the data set matches an existing record, then saveRecord will perform an update instead of a delete - even if no primary key value is present."

If all of the fields matched, then what exactly would be updated? This is more me being curious than a practical question.
# Posted By Sean Ford | 2/10/12 2:22 PM
The BLOB/CLOB fields.
# Posted By Steve Bryant | 2/10/12 2:40 PM
Hi Steve,
can this beta be used in production or, if not, when do you plan to release a stable, definitive version?
i'd update my abstract service library, based on dataMgr, to this new version.
# Posted By Salvatore Fusto | 4/5/12 8:30 AM

I had intended to get a definitive version out much earlier than now, but I am horribly behind on client work which has caused a delay.

Personally, I have been using DataMgr 2.5 in production for over a year now without trouble.

Nothing major is likely to change between this version and the gold version except the name.

# Posted By Steve Bryant | 4/5/12 9:15 AM
Ok Steve,
very well. i'll start to update my libraries.
thanks and regards
# Posted By Salvatore Fusto | 4/6/12 9:07 AM
Steve I have a question about files (images) , I am trying to pass the file image in the form scope to datamgr and it falls out (using arguments=form) on the datamgr call. When I do a hard query from the page it sets to the table correctly. I also trying to setting the form variables to a different struct and that didn't seem to work. So a direct query works, datamgr doesn't. Any idea why? Llet me know if you need more information.
# Posted By Frank Tudor | 5/29/12 11:51 AM

What method are you passing the structure to? What error message are you getting? Are you using the 2.5 Beta 3 build or another?


# Posted By Steve Bryant | 5/30/12 10:23 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.