You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of places that arrow's js package uses instanceof. For example:
// from table.ts in the Table constructor
if (args[0] instanceof Schema) {
schema = args.shift() as Schema<T>;
}
Unfortunately, this is quite brittle. This will fail whenever a library ends up with multiple instances of the arrow library. For example:
LanceDb currently uses arrow version 14. If the calling user is using any other version of arrow then node will happily install two versions of arrow and the checks will fail. (also, these failures tend to be very opaque)
I would argue that some of the core types (at least Schema but maybe also Table / Vector / RecordBatch too) should be considered stable and users should be allowed to have different versions / instances. We tried working around this in lancedb by declaring arrow a peer dependency and that solves the first bullet above but it's also somewhat unconventional (for javascript) and inconvenient for our users (they are forced to use whatever version of arrow we are using and when we change our arrow version it is a breaking change).
This is not critical, we've worked around this by re-building the schema if the input from our user looks like a schema, but I wanted to see if other JS users/maintainers felt similarly and, if so, I might try and find some time to explore a fix.
Some potential fixes:
Add methods like isArrowSchema and use those methods instead of instanceof
Describe the enhancement requested
There are a number of places that arrow's js package uses
instanceof
. For example:Unfortunately, this is quite brittle. This will fail whenever a library ends up with multiple instances of the arrow library. For example:
I would argue that some of the core types (at least
Schema
but maybe alsoTable
/Vector
/RecordBatch
too) should be considered stable and users should be allowed to have different versions / instances. We tried working around this in lancedb by declaring arrow a peer dependency and that solves the first bullet above but it's also somewhat unconventional (for javascript) and inconvenient for our users (they are forced to use whatever version of arrow we are using and when we change our arrow version it is a breaking change).This is not critical, we've worked around this by re-building the schema if the input from our user looks like a schema, but I wanted to see if other JS users/maintainers felt similarly and, if so, I might try and find some time to explore a fix.
Some potential fixes:
isArrowSchema
and use those methods instead ofinstanceof
instanceof
by implementing https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/hasInstance on types likeSchema
.Component(s)
JavaScript
The text was updated successfully, but these errors were encountered: