Em 02-11-2017 07:13, Jeremy Evans escreveu:
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.
I'm not sure I understand your proposal. I don't usually know the
mapping. The oids are usually figured out by Sequel itself when I
register a row type by name, for example. This is performed during
initialization. I don't know the oids in advance. But even if I knew, I
guess you suggested that I should perform some web request to instruct
the application to run the code above. That isn't practical if you're
running a cluster of servers because you can't guarantee that the
request will be redirected to all servers in the cluster.
I was thinking in another kind of solution. For example, when we call
DB.register_row_type, it could remember that call somewhere and then,
once it finds an OID in the result set that is not mapped yet, it could
try to check if the OIDs for the previously registered types have
changed and then re-register them. It seems that for some reason JSON
columns also stopped working after the upgrade, so maybe the OID is not
a well known value for them either. In that case, Sequel would have to
retry registering such extensions too each time an OID mapping is not
found. I understand this is usually not desired, but it could be useful.
Maybe in that mode we could get a warning message whenever an OID is not
registered, which would be triggering such an update code. This way we
would be able to try to register all used OIDs so that they would be
usually all mapped, avoiding the re-registering of OIDs.
Not sure if this is really feasible as I don't really understand the
internals of OIDs and how they are handled by Sequel.
Thanks,
Rodrigo.
--
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.
