HTML5/Async Support

[Nicholas Schlueter]

First, I would like to say that this project is going to be very
valuable once finished. I think I have said that to you in the past.

Second, I think that in the long run HTML5 is going to eclipse gears/
air usage of this library. I know you have been trying to get HTML5
working for a bit now, and are having issues getting this where you
want it. I am not 100 percent sure, but I would guess part of the
issue is supporting both async and sync databases. My solutions is a
drastic one, admittedly, but I think it is the best one, dump
synchronous support. I know you have it working, and I know that it
is way easier to program if you can rely on your statements completing
and working inline. I took 45 minutes and browsed the code base, I
firmly believe that making this project HTML5 compatible is going to
be difficult.

The crap thing is that it is the less simple API to understand. But I
believe universal API and functionality is what makes an ORM so
strong. If you can't depend on the ORM working similar across
platforms you my as well pick an abstraction appropriate for your
platform. I admit it would take a drastic change, but in the long run
it will be worth it.

Alternatively, you could just roll a different version of the library
call ImpromptuJazzRecord (Async Version) :) But that doesn't sound
like a good time maintaining multiple projects, making sure people are
pulling the right one for the right platform etc.

FWITW keep up the good work finishing this project will be a great
achievement.

[Nick Carter]

Thanks for finding the time to look things over, and thanks for the
kind words. It certainly could use some reorganization but it's come a
long way from where it was back in Aug/Sep.

I'm not sure I think it will be absolutely terrible to rejig for async
while maintaining synchronous support. It may, I guess I'm about to
find out shortly, the next time I feel up to spending a few hours I'll
be doing prep-work for my ideas to have sync and async play nice
together for finders alone, which will be the trial run. If that
proves successful, I'll abstract out the stack mechanism for recursive
asynchronous calls so it's reusable across save and destroy scenarios
as well.

The only real crazy hang-ups (other than I'm not sure how performance
will be after rejigging to use the stack, either async or sync usage)
I foresee are migrations (which I think I've mentioned before) and
validatesUniquenessOf, which is the only validation method which
incurs a db hit currently. Barring these two obstacles or nasty
performance hits, I think my stack mechanism will work for both sync
and async with minimal code bloat.

Thanks again for having a look and for the praise. I look forward to
more contributions and would love to hear from anyone who's actually
using it in terms of features they find useful or would need.

On that note, we plan on implementing a few new niceties in the near
future (most likely post-async): optional cascading destroy to
specified associations and a few more handy shortcuts for migrations.

Man, I hope migrations won't have to change much for async! My feeling
is if anything, they are the most likely feature to require two
separate codebases...