Coming nearly four months after the previous beta, DataMgr 2.2 Beta 2 is finally ready. I regret having taken so long to get this build completed, but I am happy with the results.
- New method: getFieldLengths()
- New method: removeTable()
- New relation type: "hasnot"
- Enhanced method: removeColumn()
- Enhanced method: updateRecords()
- Enhanced relation type: "math"
- Improved Seeding
- Bug Fixes
New Method: getFieldLength()
This feature was another great idea by John Whish. The method takes a table name as an argument and returns a structure of every string field with a length limit. Each key is the name of a field and each value is the maximum number of characters allowed in that field.
New Method: removeTable()
This feature was suggested by John Farrar. I have initially resisted allowing destructive changes to happen from DataMgr, but John has shown me the light. I now have destructive features, but they must be called explicitely (I may allow an option for the "loadXml" method to be destructive, but I haven't decided yet).
This method takes a table name as an argument and removes it from DataMgr's memory as well as the database itself.
New Relation Type: "hasnot"
I added the "has" relation type in DataMgr 2.2 Alpha 2. It indicates "true" for string fields with a length of more than zero or numeric fields with a value greater than zero or non-null date fields, false in other case. The "hasnot" relation field simply returns the opposite boolean value.
Enhanced Method: removeColumn()
Andrea Campolonghi rightly pointed out that this method should work on relation fields as well as database fields. So, now it does.
Enhanced Method: updateRecords()
The "data_where" argument is now optional - allowing this method to be used to update every record in a table.
Enhanced Relation Type: "math
I added the "math" relation type in DataMgr 2.2 Alpha 2. I have changed it so that either "field" argument will accept either a field name or a number to be used in the math. I initially decided against this as I wanted to discourage hard-coding values. Then I needed to do some math with "60" (for the number of minutes in an hour) and changed my mind.
This was another great suggestion from John Farrar. One of the problems with seeding data with the "loadXml" method has always been that it is difficult to change the data for new versions of a product.
John suggested added a "checkFields" attribute to the "data" element. This specifies which combination of fields should be checked for existence to decide if a record should be added to the database. The attribute is a comma-delimited list of fields.
So, without this attribute, a record will be added to the table unless a record is found matching every field in the row. With the "checkFields" attribute, it will only be added if no record is found matching the values of the fields in the "checkFields" list (this only matters if permanentRows is set to "true").
Description="I manage site administrators and administrative logins."
Description="I track errors and bugs."
Description="I manage events and optionally display on calendar - includes repeating events."
With the above example, I could change any field other than "ProgramName" or "ZipFinal" (the fields in the "checkFields" attribute) and it would result in the record being changed instead of added.
This build also included a number of bug fixes. I thought it would be helpful if I listed those fixes briefly this time.
- issue with date fields
- Object returned from init()
- Potential for duplicate field in "ORDER BY"
- "IN" filter
- Filtering for empty strings as NULL
- Potential syntax error in update
- Limitation with concat in MSSQL
- Database introspection in Oracle