Jesse and I have started to play with git and will be resuming moving forward with testing and refactoring things for the time being.

A short ways down the road, however, there will be a somewhat large change where I’ll be converting JazzRecord to be an independent library not based in MooTools. The reasoning is basically that with no dependency, more users will be inclined to accept it and move on with their app creation.

I’ve been in contact today with Uriel Kats, developer of another JavaScript ORM, JStORM. JStORM has similar syntax for some of it, but he tells me his is rooted in Django whereas my library is rooted in ActiveRecord. We’ve both expressed interest in learning from one another. I’m certain to borrow some ideas from his code! He’s got JOINs implemented already, for one, a major stumbling block for me! His code is also pretty terse and easy to read.

If you come from Django and are looking for ORM in JS, perhaps you’d better take a look at JStORM!

If you’re down with ActiveRecord, hang around. We’ve got some cool stuff coming still.

JazzRecord.org is now up, with a working, not quite up-to-date version of the library to work with. There’s also a live demo for tooling around w/ Gears, JazzRecord, and Firebug.

We will be switching to Github soonish, and will probably link there directly for the nightly copy. We’ve still got to work out our versioning/release process.

As well, we’ve made several changes of note since I last blogged:

• Validation is solid: The previous concept of having a single validate() method has been replaced with three optional methods: validateAtCreate(), validateAtUpdate(), and validateAtSave(). These are run prior to initial record insertion or updating respectively for the first two, and on any save for the last. Almost all ActiveRecord validation methods have been ported over for use in these user-defined methods.

  The Record.errors array contains any errors generated during the save process, or a direct call to isValid().

• Improper data is coerced into the correct type prior to saving the record, as in ActiveRecord. What this means is that, though the data might not be meaningful, it is at least valid in terms of the schema.

• We’ve begun adding support for “dirty records” and will be supporting a good portion of the Rails 2.1 capabilities in this vein.

• Autolinking and unlinking of associations is coming along. So far, hasOne and belongsTo associations are supported. We hope to have all 4 association types supported within a week.

  Basically, you can assign a record object directly to the named association property of a base record, and when the base record is saved it will rewrite its foreign key with the ID of the newly-associated record. It also works the other way round (assigning the foreign key property manually will cause the associated record to load after saving the base record).

  Taking it one step further, if you reassign a hasOne relationship so that it points to a new record, the original record which belonged to the base record will have its foreign key deleted and the new record will have it assigned in its place.

  Similarly, deleting a named association property (or, again, the associated foreign key) or setting it to null will unlink the two records by whichever means is necessary, given the association type. For instance, in a belongsTo relationship, the record which belongs to another record will have its foreign key deleted.

  The hasMany and hasAndBelongsToMany association types will soon behave as expected, but a little more infrastructure needs to be added before hasMany will work. Removing an item from the array of “many” returned for the associated collection of records will cause that record’s foreign key (corresponding to the base record’s ID) to be deleted.

• Have begun writing automated test scripts using JSSpec, and will be building them out extensively over the next few days so we can truly claim it’s been tested and is solid.

This all goes a long way to making JazzRecord closer to being feature-complete and ready for action.

Both David and Jesse are fairly new to JavaScript, new to MooTools, and have had no previous part in working with this project. David has had some learning experience with Rails/ActiveRecord and that helps in understanding usage of TR tremendously. Jesse has been studying programming in his spare time for the past year or so, and has caught on very quickly.

David is working on rounding out our Migration capabilities, filling in the holes sqlite leaves us with in terms of modifying columns and adding some additional functionality after that. He also improved the find() method on Model so it can accept arrays as in ActiveRecord.

Jesse has so far contributed to adding support for a few new storage datatypes and is in the process of wiring up validations for said types. He has also worked on some of the automigration code.

Tonight and last night I added a lot of code myself:

1. Fixtures are now fully supported, including mapping tables. Automigrations will now create tables (also including mapping tables for N:N relationships) and load all data presented in fixtures.
2. Added AssociationLoader class. This is useful for loading data post-preloading. More on this below.
3. Added event-handling to Record objects. This can be configured in Model declarations or added after instantiation of a Record object.
4. Wired up Jesse’s main validation methods to Record.save and added user-configurable validate function to Model constructor.
5. Wired up Jesse’s new datatypes to Record save/initialize methods.

Preloading happens when a Record object is first created after a call to Model.find or similar method. ThyncRecord only loads associated data to a configurable depth, which can also be overridden in the find call itself. If deeper data is needed, simply calling recordObject.load(”associationName”) will fill the target association with the correct data. I basically implemented this as a replacement for dynamic loading of properties in ActiveRecord, since JavaScript has no accessor methods which act like properties. (though ActionScript does, and I just came across similar syntax in Mozilla’s JS 1.5 documentation…)

I’m really excited by how much progress we’re making, and looking forward to releasing it all shortly. I can see it as being a boon to AIR developers and Gears-heads alike.

Quick question: Is the name ThyncRecord ridiculous? If so, what are some kick-ass names the good folks of the Interwebs would like to bestow on this project?

[EDIT: ThyncRecord is now JazzRecord and will be available for download from www.jazzrecord.org starting 10/21/08]

Control Diagram for ThyncRecord

This is a reposting of an email I sent Frank Lee, who I’ve tapped to help out in building optimized queries for ThyncRecord. Just figured I’d share.

“Because of [JavaScript's prototype-based inheritance vs normal OOP], there is no proper concept of class methods and instance methods. (I don’t believe moo has implemented such a feature yet, though it may in the future…) So, whereas in ActiveRecord’s Ruby implementation we have a model class which returns instances of itself when queried using class methods, I’ve had to invoke a second class called Record, which is a mostly dumb object with a few key methods (save, destroy, reload) and access to associated records within the database. To accomplish this, we need to preload data as deep as seems reasonable to obtain quickly and map it out to dynamically-generated objects which are then assigned to the associated properties.

To generate the SQL for a query, it is necessary to examine a particular model’s associations and the associated models’ associations, recursively until we reach the appropriately-defined depth. It is of course also necessary to know the data type for each column of the currently-being-built object, It is most important to know upon save, preventing improper types being stored in the db, formatting the query strings appropriately with quotes or without, outputting error messaging, etc. Likewise validation rules may output similar error messaging, as defined by the user of the library via regex. (may implement add’l validation in the future)

Associations which can be defined should include at a minimum: belongsto and hasone, which are essentially the same thing but seen from different perspectives; hasmany, which maps an array of the associated model’s Records to a plural property name on the root Record object; and hasandbelongsto_many, which will map an array of associated Records from either end. Determining where to cutoff preloading of these properties is a significant decision to make still. Preventing circular references, etc may be important.

Data types need further fleshing out as well, I currently have only been dealing with number and text, since SQLite does little to prevent storing improper types in the db. (it does, however, provide some base functions which may be used to provide some additional validation beyond application-level if we thought it was necessary) Likewise, JavaScript makes type checking harder than it is in most languages. We certainly should at a minimum include a date type of some kind, I believe SQLite has another built-in function for current timestamp, etc…

An example of ThyncRecord usage would be storing various users’ payment info. We might define a User model and a PaymentMethod model, where the User hasmany PaymentMethods, and a PaymentMethod belongsto a User. All of this is accomplished declaratively (along with defining all columns and add’l validation). Schema is created by means of migrations or model declarations alone. (I may also implement the Rails concept of fixtures which will load data directly into the db from formatted text, in this case JSON) A call to return the second payment type for user 3 might be:

var payment_meth = User.find(3).payment_methods[1];

Let’s also presume that this new object is assigned an ID of 543, (it’s record 543 in the payment_methods table) though the user needs not know of this. You might then update the billing address (a text field) of this payment method (we can assume it’s a credit card, perhaps):

payment_meth.billing_address = "123 Some Place, Sometown, ZZ 90876";
payment_meth.save();

Calling save will first verify that some data has changed from the initially-loaded state, and if it has it will pass over into the validation process for any sub-objects first, then on to the current Record. In this case we have no sub-objects, only a text field to worry about. It should write out something like

"UPDATE payment_methods SET billing_address='123 Some Place, Sometown, ZZ 90876' WHERE id=543";

The Record object passes back the updated data to its corresponding Model (all Records contain a key to the master models hash stored in ThyncRecord for the purposes of navigating through associations).”

Anybody w/ questions or who feels like contributing, feel free to email me (thynctank@thynctank.com).

[EDIT: ThyncRecord is now JazzRecord and will be available for download from www.jazzrecord.org starting 10/21/08]

I’ve recently begun using Adobe AIR (specifically using JavaScript) and am really excited about it. Have had a friend install an unsigned demo of some of my interface code and he said it worked great! This code is for a scalable/syncable task manager I’ve set aside until I can get some more database-centric groundwork done. This app has me excited for my own personal use as well as the possibility of widespread use by Windows and Mac users. For a great reference after wading through some intro material, check the free PDF of Adobe AIR for JavaScript Developers Pocketguide, which Adobe has kindly released into the wild.

Almost all of my current personal work involves MooTools 1.2, and I love the Class-building capabilities. Having not written a great deal of OOP stuff with 1.1 I can’t compare, but the Options and Chaining stuff are very exciting, as are Element storage and Hashes. I’m currently using Options all over, may use Chaining, and am using Hash as well as Element storage in the task manager project. String methods like substitute() and clean() are a welcome addition! So are many of the core functions like $random and $extend. $extend, in particular, makes up for not having a directly-overridden Object class.

The aforementioned db groundwork, which I’ve dubbed ThyncRecord, is seeing a lot of progress. I’m about 300 lines into it and don’t foresee it going much beyond 700 at this point, even though at various times I’ve thought it would be much heavier. Have yet to test performance but I’ve already got some ideas for clearing bottlenecks, mostly involving custom events for asyncrhonous loading if necessary. I currently have a default limit to how deep the recursion can get for loading associated model data into a record, and this can be overridden as necessary.

Schlueter gave me the idea of abstracting the code out to be useful to Google Gears code as well, which I may take a look at once I’m happy with how things work using AIR’s SQLite. It shouldn’t be too much trouble working with another project as long as it’s SQLite as well.

Finishing up Association handling, adding in validation and implementing a migration system are next up for ThyncRecord. What I have so far is pretty polished and organized, though it’s taken several revisions and lots of meditative car rides to get it where it is now. It currently responds as similarly to ActiveRecord as is possible within JavaScript. Almost all options for finders are available in ThyncRecord, and currently belongs_to associations work fine. HM and HABTM are next.

I look forward to releasing ThyncRecord for public consumption once it’s ready, and welcome comments or questions in the meantime. Again, it primarily targets the AIR crowd but will eventually work in other environments as well. It requires MooTools 1.2 to work, and I’ll release full documentation and requirements once it’s good to go.

On a side note, RideCharge is looking for a QA Specialist. The ideal candidate can write automated tests in addition to normal QA activity. If you have any more questions contact thynctank@thynctank.com or careers@ridecharge.com.

P.S. - the Gracefully Degrading Widgets articles will continue eventually!

[EDIT: ThyncRecord is now JazzRecord and will be available for download from www.jazzrecord.org starting 10/21/08]