On Wednesday, November 1, 2017 at 9:34:16 PM UTC+1, Rodrigo Rosenfeld Rosas
wrote:
>
> Ok, thank you Jeremy. I was just wondering that when you get the data from
> some query you would get the oid for the columns and then you'd be able to
> detect whenever an OID mapping is missing and some default mechanism is
> being used to handle it. In that case, it would be an opportunity for the
> application to try to re-register the field types. This is similar to when
> we ask Sequel to run something like "select 1" before any statement to make
> sure the connection is valid. It adds some overhead but for many
> applications we would prefer such an overhead over an error for each
> connection in the pool when the database is restarted for example. The same
> way, I could live with an overhead of always checking for OID change
> whenever an OID is not mapped in the application if it would allow me to
> make upgrades quicker.
>
I thought about this some more and one thing you could do is create a
mapping of the OIDs from the previous version to OIDs of the next version
where the OIDs have changed. then you could do:
oid_map.each do |from, to|
DB.conversion_procs[to] = DB.conversion_procs[from]
end
You would do that after setting up the conversion procs for the previous
version, and before freezing the database. As long as there was no overlap
between the keys and values of the hash, that should allow upgrades across
a single version to work transparently and still allow for a frozen
Database object.
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.