Tag: SQLEditor

  • SQLEditor 4.0

    After a bit of a gap, SQLEditor 4 is now pretty much at the point of a public release.

    Thanks to everyone who has been trying beta versions and the most helpful bug reports!

  • SQLEditor Dark Mode Canvas

    Recently I’ve been working on providing SQLEditor with a dark mode canvas and here is the current development version (running in dark mode):

    This work should hopefully appear in the next beta release.

    And of course, with SQLEditor you can choose which option you like, whether light UI with light content, dark UI with light content or now dark UI with dark content.

    Coming soon!

  • Rails Migrations and Schemas

    • A schema.rb file is typically a ruby script containing a call to the ActiveRecord::Schema.define method.
    • A rails migration is a ruby class which inherits from ActiveRecord::Migration and contains a method called up

    The useful fact that I realized only after doing some ultimately unnecessary work today is that because the schema file contains a method call, it’s actually easier to extract the information from it than with a migration (which needs SQLEditor to figure out a class name and then call the up method)

    Hopefully this new work will appear soon in SQLEditor

  • SQLEditor 1.6 final

    So, if you’ve seen SQLEditor recently, you’ll hopefully have seen that there is a new version out: version 1.6. This got released just at the beginning of December 2009

    1.6 is something that I’ve been working on now for a long time, it is essentially (the unreleased) version 1.5 with improvements and updates. In particular it contains a SQL parser that was written using ANTLR and a new JNI based system for using JDBC drivers with support for Java 6 JDBC drivers.

    It’s also the first release version of SQLEditor that is compatible with Snow Leopard. SQLEditor 1.4.7 and earlier had an unusual architecture. When I originally started writing SQLEditor, it was a Java application with a Swing user interface. After some development it seemed clear that java swing was proving limited in some ways. I rewrote the user interface layer in Cocoa, leaving the model layer in Java and using Cocoa Java to connect the two parts together. The application development continued and new versions were released. Eventually though, Apple decided that Cocoa Java was not the future and decided to deprecate it.

    Work began immediately on rewriting the crucial components of SQLEditor, although there were some issues.

    The first was the model code. Every object in an SQLEditor document is represented by an object and all of the code for these objects was written in Java. All of the object code was rewritten and tested against the earlier versions to check that it still worked. It was very important that files from previous versions continued to work (and as far as I know all of them so far do). New code was written to read and write the SQLEditor document xml format.

    The second major issue was that the database interface used JDBC drivers, which are written in Java. Native code would use ODBC drivers. Although similar this might mean that users wouldn’t be able to use existing arrangements to access databases.

    Eventually code was written to bridge between SQLEditor native code and the JDBC drivers using the Java Native Interface (JNI).

    The other crucial problem was the SQL parser. This is used if you paste SQL code into SQLEditor or if you import a file. The SQL parser was written using JavaCC, a parser generator that is written in and produces Java code. Several parser generators were looked at to replace JavaCC and eventually ANTLR was chosen.

    A new SQL parser was written and tested during 2009 in ANTLR and is included in SQLEditor 1.6. The new parser is completely rewritten compared to the one that existed in SQLEditor 1.4.7 and no code is shared between them.

    A major step in developing the new parser was to port all of the SQL test cases from Java (in 1.4.7) to objective C (in 1.6). These automated unit tests are run against the parser to ensure that the new parser behaves correctly compared to both the 1.4.7 parser and the assorted SQL standards.

    It is still something of a work in progress though, there are things it doesn’t support and it’s still being actively worked on. One particular thing that makes this somewhat harder than it might otherwise be is that it must accept SQL in several different dialects, not just a single standard.

    SQLEditor 1.6 also included user interface improvements and various performance fixes.

    Overall it’s an improved program, although I do wish that it had been released sooner.

    Thanks to everyone using SQLEditor for your patience and also for trying the beta versions.

  • SQLEditor 1.4.4 Released

    SQLEditor 1.4.4 was just released on Tuesday, the main feature improvement is the support for compound foreign keys. I posted a bit about this before and the final version is pretty much the same as I described.

    Unfortunately there were a couple of bugs that slipped through relating to clicking objects. 🙁

    These are going to be fixed in a point release that should appear soon.

    The new version is available from the automatic update system or download here:


    3.9MB dmg File
    Change Log
    Product Notes
    Expires
    21st January 2009
  • SQLEditor: Compound Foreign Keys

    The newest version of SQLEditor (1.4.4b1) now has support for compound foreign keys. This is something that people have been asking about for a while now, so I’m pleased that it got included.

    There are some things that may need to be improved, but I’m fairly happy with the first revision of this.

    Diagram showing compound foreign key
    Diagram showing compound foreign key

    The compound foreign key object is a new table level object that you can add from the Object menu just like a field or index. Then you drag from the foreign key to the target table. Finally you use the inspector to create pairs of columns to link together.

    When importing from a database SQLEditor will try to create field-to-field links on foreign keys with only 1 pair of columns unless you tell it otherwise. (There is a new preference to do this)

    Support is fairly complete, SQL parsing, database import, database export and SQL export are all available so it should work fairly well. I think the only thing it doesn’t do is auto-create indexes, so you may need to do this by hand on referenced columns (for those databases that need this)

    There is naturally a new inspector palette to go with the table object.

    Compound foreign key inspector
    Compound foreign key inspector

    This allows you to add pairs of columns using the + button at the bottom. Choose your columns using the little popup menus.

    The whole thing is completely new, so please send in your thoughts to the usual address.

    Download SQLEditor 1.4.4b1

    (or enable the “Check for beta versions” preference and then use the check for updates feature)

  • SQLEditor 1.4.3b3

    So, it’s coming up to the holidays, but there is time for another SQLEditor release.

    1.4.3b3 (snappy numbering, yes?) is pretty much a bug fix release. I think that the index creation problems that were happening have now been fixed, plus better handling of when to create indexes. It should now correctly figure out if fields are indexed and shouldn’t now add duplicates (or worse attempt to add duplicates)

    There is also the addition of the simulate mode for database export. This isn’t exactly new, because it’s been available in some development builds, but it has now appeared in a release version. Simulate mode runs the entire export as normal, except that instructions that alter the database aren’t actually sent to the database to be executed. The instructions are recorded though, so you can see what would have happened in the status window log view.

    There is also a new feature which prevents fields and indexes being dropped (although it doesn’t prevent modification, use simulate if that’s what you want)

    SQLEditor also now adds a line in the status window when an export fails complete with the instructions that were actually executed and the error that occurred. This information was always in the log, but it should be easier to see how SQLEditor has gone wrong (in the event that it does of course)

    Finally some fixes for a few (hopefully unlikely) crashing bugs.

    3.6MB dmg File

    Change Log
    Product Notes
    Expires
    21st January 2009

  • MySQL before 4.1?

    This graph appears to show that most people polled (97%) are using MySQL 4.1 or later

    This second poll shows, again, that most people (89%) are using 4.1 or later.

    The thread at the PunBB forum gives 95% of people polled using 4.1 or later.

    The Mambo forum poll from 2006 gives 80% using versions after 4.1 (with 8.5% don’t know or other)

    Admittedly not scientific surveys (self selection, etc) but somewhat convincing.

    This has an obvious implication on how to handle MySQL support, in particular special casing to work around particular issues in early versions. This code adds complexity and in some unfortunate cases also bugs. The less there is, the better.

  • SQLEditor updates

    I’ve just released a new version of SQLEditor yesterday, mainly as a bug fix release, but it’s definitely recommended to upgrade.

    The new beta is 1.4.3b1 which was released 14th November. It fixes a number of bugs, including MySQL comments and some odd bugs relating to selecting tables using the drag selection method.

    Download 1.4.3b1 (3.6MB DMG)

    The current stable version is 1.4.2 which came out at the end of October. It fixed several significant bugs that people reported and made a few minor improvements.

    Download 1.4.2 (3.6MB DMG)

  • Django Support

    Several people have now asked for this, so it’s being really seriously looked at.

    Plus I’m hopeful that it will be able to support the somewhat different but quite similar Google app engine model class format too

    Having been working on this for the last few days, I can say that the Django plugin is moving towards a working state, the development version is now somewhat able to create and export a suitable python file.

    Although this mustn’t be taken to mean that it’s near to release, because there are still several major things that are needed before it will be complete.

    I think there will probably be two releases, the first will be export only, then a later release will add the import features.

    And it should be a free upgrade for SQLEditor 🙂