On Thursday, November 2, 2017 at 12:39:55 PM UTC+1, Rodrigo Rosenfeld Rosas wrote: > > 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. >
Sequel obviously can figure out the type OID from the type name. Review the related Sequel code for how to do that. It isn't that complicated, though I admit it's not simple either. If you expect a database upgrade during the running life of the application, then at startup, connect to both the old and new databases, and get the OIDs. If you don't currently have the ability, build it. But it needs to be done on initialization and not while the program is running. 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. > Not really feasible, as you will see if you review the code related code. Sequel does a type name -> OID query, and you don't have a type name, only a new OID. Plus it is common in Sequel to not have OID conversion procs registered for types actively used, since that is faster for string types. You would have to differentiate those OIDs from the OIDs you care about and want to convert. Even if you could get it to work, it would likely be subject to race conditions. 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.
