Model issues in TitaniumDeveloper (Desktop)

[rudylattae]

I am having problems using JazzRecord with TitaniumDeveloper (1.2.1). I've tried it on both Winblows (XP Pro SP3) and Linux (Ubuntu 8.04 - Hardy Heron).

It looks like I am able to connect to a db ok:

JazzRecord.adapter = new JazzRecord.TitaniumAdapter({dbFile: 'junky'});

I create my model and automigrate it ok:

JunkModel = new JazzRecord.Model({
    table: 'junk_models',
    columns: {
        title: 'string',
        description: 'string'
    }
});
JazzRecord.migrations = {};
JazzRecord.migrate();

I can even create a new instance of a model:

var junk = JunkModel.create({
    title: 'Drink some junk',
    description: 'Some serious junk for you!'
});

// using Jasmine sweetness to BDD my way through it, I can:
expect(junk.id).not.toBe(null);    // passes
expect(junk.title).toEqual('Drink some junk');    // passes

What I cannot seem to do is to .save() a record or read in any records from the db. Any of those actions generate a "Not found" error and that makes Jazz puke.

junk.title = 'Fresh junk';
junk.save();   // throws a "Not found" error
var junks = JunkModel.all();   // throws a "Not found" error

The interesting thing is that "create()" successfully creates a new model instance and persists the provided data to the db. Anything beyond that fails miserably.

I know JazzRecord is still in development so I can't hold out too much hope for it being feature complete. The reason I am attempting to use it is that I am working on a tiny Titanium Developer (Desktop) application and I have gotten to the point where I don't want to be messing with model specific SQL. I put on a brave face and was on my way to hack up a model wrapper for the Titanium.DB API when I JR caught my eye. Compared to Impel and persistencejs. JR comes closest to meeting my needs with regards to Titanium DB API support (or lack thereof :p), pluggable db adapters and fluent pure javascript syntax.

Before giving up, I will go ahead and try to dive into the source and see if there are any rapid fixes I can contribute. In the mean time, I would like to know what your plans are for supporting the current and future iterations of Titanium. Specifically:

• Will you be able to take a look at the JSSpec specs in TD 1.2.1? I run them and out of 80 examples, there are 2 failures and 5 errors in the "Model" and "Auto-linking and unlinking" spec groups.
• Is there a time frame for having reasonably complete coverage for Titanium?

Even if I end up not using JazzRecord, I should mention that I was very impressed with it. The implementation of the db wrapper is very slik and I'm sure once you throw call back support into the mix, things will get all kinds of funky fresh! Good job and all the best.

PS: I'll update this issue if I proceed any further with it.

[thynctank]

Apologies for this not being made clear (I'll update the readme tonight) but Titanium has a bug (see https://appcelerator.lighthouseapp.com/projects/25719/tickets/425-null-values-return-as-typecast-values-rather-than-null) that is causing serious issues involving NULL values in the db. They come back as empty strings, or 0s, etc depending on type of column. This occurs before it's ever handed to JR.

Hopefully this is all that's between JR and total domination in TI.

Just so it's clear, there is a full test suite for JR (it's JSSpec-based), and there are only a handful of failures/errors. Once desktop is working will make sure mobile is working.

I really appreciate your detailed report.

Thanks for the kind words about JR!

I'm not sure I'll be adding async/callback support, (it definitely wouldn't feel like Rails' ActiveRecord) but if there's enough interest I'd be more inclined to do so. Anyone who wants to could always fork it!

[rudylattae]

Thanks for the response thynctank. I added a few more examples to my specs and noticed the exact behavior you mentioned TI is exhibiting:

• given an integer field with NULL value, TI auto sets that value to 0
• given a string field with NULL value, TI auto sets the field to '1'

I'm watching the TI bug to see if they will be able to resolve it soon. It's been marked as low priority so I am not holding my breath.

I took another look at this issue and I am still a bit confused with regards to the JR side of the coin. I see that TI messes up when you give it a query with fields that have null values. However, I still get the 'Not Found' error thrown when I try to do mundane stuff. E.g.: I enter two records into my table (all with NON-NULL field values). When I try to read the data (the two records) in my table with either of the following:

• JunkModel.find(1) which executes the SQL "SELECT * FROM junk_models WHERE id=1 LIMIT 1"
• JunkModel.all() => "SELECT * FROM junk_models"

I still get a "Not found" error. However, if I run these same statements through the TI Database api, they work as expected. What gives? I think I'm missing something here.

I'm going to take a deeper look at the Gears wrapper since the TitaniumAdapter delegates to it. My hope is that I can find a potential work around for this wart until TI fixes the root issue on their end.

[michaek]

I'm with @rudylattae on this one - I don't think all the errors JR is throwing can be ascribed to the Ti null bug. Unfortunately, their lighthouse project doesn't seem to be publicly accessible anymore. I'll try to see if I can shed some light...

[michaek]

I wasn't able to get any further with this, and it seems like I'll be a lot happier if I just write a Titanium Database interface for backbone.js, similar to http://documentcloud.github.com/backbone/docs/backbone-localstorage.html. It doesn't really seem like there's much demand for closing this issue, anyhow. :)

[thynctank]

Thanks for having a look at JR, but yeah it doesn't seem like there's much interest in web sql at this point in general, and async just wasn't going to happen to this project. Apologies for not responding sooner, hadn't seen the messages on github... I may have a look at this again soon, but I've obviously lost steam for this project.

[michaek]

That's totally understandable, and no worries about not responding! I think an ActiveRecord implementation for Javascript was a great idea, and JazzRecord was working very well for me under AIR. The tighter integration between views and models in backbone.js is pretty appealing, and it's reason enough for me to look at extending their persistence rather than trying to shoehorn in yet another model. :) Currently, I've got my Titanium app working with the localstorage module I linked to, and it's now a matter of swapping in a more scalable database for storage.

[rudylattae]

No problems here, this issue was not within your control. Thanks for this awesome tool and all the best with any future renditions.