Project Elbow: Working with flash.data.SQL

Getting back into 100% gear mode today, less spaz, more bacon. Trying to learn AIR’s on-board SQL server before work.
 ·  · Share
    • Joe Winett And, wouldn’t you know it, it’s easy. I swear, everything Macromedia and then Adobe did with Flash/Flex/AIR is easy.

      about an hour ago · 
    • Joe Winett And, of course, all SQL operations can be done asynchronously. As far as I can tell, there’s not really a threading system in a Flash application. There are just asynchronous operations and whatever is happening in your UI right then. How the work is broken up in the background, I don’t know… I guess I don’t need to know.

      about an hour ago · 
    • Joe Winett Well, crap, they just answered that question. An asynchronous SQL connection executes it’s commands in its own thread so your main application thread can go about doing its own thing. Your thread then responds to events indicating what happened.

      59 minutes ago · 
    • Joe Winett I suppose it’s all easy if you’re already used to working in an event-driven environment.

      59 minutes ago · 
    • Joe Winett That was pretty easy.

      36 minutes ago · 
    • Joe Winett ‎5:48!! Hurry.

      30 minutes ago · 
    • Joe Winett The FileManager needs to do a CREATE TABLE IF NOT EXISTS command right after opening. Sometimes it’s cool to keep track of a state variable to figure out what you’re supposed to do next, but sometime’s it’s cooler just to have a different listener function for the next statement. It’s a different event anyway… Wasting time…

      28 minutes ago · 
    • Joe Winett Oh no. You can store BLOBs up to 256mb in the database. Hmmm…

      17 minutes ago · 
    • Joe Winett ‎6:01!!

      17 minutes ago · 
    • Joe Winett It would be pretty handy to have it right there… But, if I want to load a SWF file and it’s 10mb… and it’s in the database, I guess I’d load it into memory and then into the actual Flash loader to use it. I don’t know why that would be a problem on modern systems… (memory is file is memory is don’t care)

      15 minutes ago · 
    • Joe Winett This would hide the files from the users on the computer and I wouldn’t have to worry about something being mucked with as much.

      14 minutes ago · 
    • Joe Winett Not right now.

      13 minutes ago · 
    • Joe Winett Holy crap you can just store ActionScript objects in there.

      12 minutes ago · 
    • Joe Winett I guess that means I could just create the Bitmap and SWF objects and store them… no BLOBs required.

      11 minutes ago · 
    • Joe Winett These Adobe guys…

      11 minutes ago · 
    • Joe Winett Ok, that’s enough. Got to put this in my blog.

      2 minutes ago · 
      ** SO what’s probably going to happen is that I’m going to do away with the file-system based cache thing I did… download the files from the service and then create the objects Flash will eventually use and store them directly in the database.  So when I need them, the FileManager will look in the database for the ID and then just return the object if it’s there.

      I still have the issue of dealing with named files… a mapping of a logical name to a file ID.  The content of named files could change (for instance, an application manifest) so this is good.  

      The FileManager won’t be responsible for messing with that… There’ll just be a second type of loader that looks for a named file.  The FileManager will ask the service for the ID that goes with the name, then check the cache for that ID, then go on from there.

      Some experimentation will be needed before I just dump the file-system stuff.

      Anyway, this was a pretty good 90 minute session this morning.  I think doing this every day will help keep me sane because the thing that drives me crazy the most is the feeling that I’m not getting anything done.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.