[Nitro] [PATCH] many to many rich association handling non saved records

Jonathan Buch john at oxyliquit.de
Fri Apr 6 04:58:55 EDT 2007


sorry for the delay!

> Which is an interesting point:

Yes, this is interesting indeed.

> Is there a policy level decision on how to treat unsaved objects?
> Should they be silently saved whenever we need an oid for them?

The current policy would be:  save whenever we require an oid.
(at least the relation code seems to tell me so)

> My gut reaction is that it's not the right behavior.  It's confusing,
> and as Og settles and matures, I'd lay odds that it becomes the most
> frequent source of frustration for new and old hands.

I think I never found it frustrating from the programmers point of
view, as it just never 'fails' per se.
What it could create, is wasting roundtrips to the database, because
the relationship object is getting saved by the user later again.

> A possibility that presents itself: adapt sequences from postgres to
> autoincrement-only dbs (just a table with an auto-increment column),
> and if we need an oid for an unsaved model object (and here, I want to
> call them entities...) grab the next_sequence for that table, and
> stick it in the oid.


    This brings a age old idea from me back.  It is about Og storing
    meta information about itself in the database.  What now
    `create_field_map(klass)` does (ordering of the fields in a table,
    available fields etc, used for example by Evolution for updating
    the tables) could be cached in the database.

    class Model
      attr_accessor :name, String
      attr_accessor :ogtable, String, :primary_key => true
      attr_accessor :fields, Array
      attr_accessor :primary_key, String

      # emulate Postgresql sequences when mysql/sqlite
      attr_accessor :seq_last_value, Fixnum

    Then use `Og.create_schema = true` to create this table and its
    contentents.  This would speed up the startup time quite some I
    would imagine (with many models, this can be a pain).

I'm just not sure about the safety of using such a method on
mysql, would an access to the sequence have to be protected by a

> Off the top of my head, one consequence would be that any
> relation-following would need an adaptor class to find unsaved
> destinations, so there's some complexity to not silently saving.


class Og::NotSavedError < Og::Error; end

so, wherever a .save right now is in the code, just raise the error.

I'm not yet clear if that is the right path to take, but it would
be a possibility.
But like I said, I don't really see a problem with the current
approach, as it 'just works'.


Feel the love

More information about the Nitro-general mailing list