Support `object_name` in all `from_` formats #14

dberenbaum · 2024-07-11T13:55:31Z

Closes https://github.com/iterative/dvcx/issues/1710

Replaces parse_parquet/parse_csv with from_parquet/from_csv (replacing other from_csv)
Keeps parse_tabular() as a public method for more complex logic (like doing complex filtering before parsing parquet)
Adds object_name (taken from from_json but name suggestions welcome) to from_storage/from_features/from_pandas/from_parquet/from_csv

dberenbaum · 2024-07-11T13:58:15Z

src/datachain/lib/udf.py

+                else obj
+                if isinstance(obj, tuple)


If expected output was of type Feature and return value was a tuple, it was being wrapped in another tuple instead of returned as is

volkfox · 2024-07-11T16:43:59Z

examples/json-csv-reader.py

    print(static_csv_ds.to_pandas())

    uri = "gs://datachain-demo/laion-aesthetics-csv"
    print()
    print("========================================================================")
    print("dynamic CSV with header schema test parsing 3M objects")
    print("========================================================================")
-    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion", show_schema=True)
+    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion")
+    dynamic_csv_ds.print_schema()


ds.print_schema() and the argument show_schema=True serve different purposes.

The former just prints the entire schema for the datachain.
The latter is a check if the CSV/JSON was auto-schemed correctly; if not, the user will need to specify a schema manually.

We can add show_schema to all these methods but would like some consensus on if it's desirable since it seems a bit superfluous with the schema-related methods added recently by @dmpetrov. Previously, these methods were always printing the schema of the table if it was inferred but @dmpetrov commented here about it looking like a strange side effect, so I dropped it.

There are important differences there.

If you are trying to read a new CSV/JSON file, you likely want to check the schema but also will probably copy-paste the output if you want to modify it.

ds.print_schema() does not serve this purpose.

I can talk to Dmitry if needed as we already had this convo.

You can get back the actual schema, though, which seems more useful than a print statement since you can parse it, validate it, and modify it. For example, you could do DataChain.from_csv(uri, object_name="csv").schema["csv"] to get the pydantic-like feature class (I think having something like schema.to_dict() might also be nice).

DataChain.from_csv(uri, object_name="csv").schema["csv"]

how does it help to copy-paste the schema to correct the errors?

Also I think you don't want to parse a 500Gb CSV file just to discover your auto-schema was wrong.
Maybe we should have show_csv_schema() as a companion to show_json_schema() to address this.

how does it help to copy-paste the schema to correct the errors?

That's why I mentioned schema.to_dict() would be nice. Then you could edit the dict and pass it back.

Also I think you don't want to parse a 500Gb CSV file just to discover your auto-schema was wrong. Maybe we should have show_csv_schema() as a companion to show_json_schema() to address this.

Only a single block (10k lines) will be parsed to infer the schema (this is how arrow does it). Like all other chain operations, the processing happens lazily.

DataChain.from_csv(uri, object_name="csv").schema["csv"]

This seems to be the right approach for examine the schema alongside print_schema() Otherwise, we will need to introduce similar side effects to all parsing methods which explodes API and not considering a good practice.

We can potentially consider improving print_schema() for example by limiting number of outputs like print_schema("csv", "file")

Only a single block (10k lines) will be parsed to infer the schema (this is how arrow does it). Like all other chain operations, the processing happens lazily.

This is not intuitive but might be just okay.

What's not okay is not to offer a copy-paste Feature or Pydantic-to-feature schema output.
Note that neither print_schema() nor schema() gets us there (the latter should actually be renamed model():

>>> chain.schema["mistral_response"] <class '__main__.MistralModel'> >>> chain.schema["mistral_response"].schema() {'$defs': {'CompletionResponseChoice': {'properties': {'message': {'allOf': [{'$ref': '#/$defs/MyChatMessage'}], 'default': {'role': '', 'content': ''}}}, 'title': 'CompletionResponseChoice', 'type': 'object'}, 'MyChatMessage': {'properties': {'role': {'default': '', 'title': 'Role', 'type': 'string'}, 'content': {'default': '', 'title': 'Content', 'type': 'string'}}, 'title': 'MyChatMessage', 'type': 'object'}, 'Usage': {'properties': {'prompt_tokens': {'default': 0, 'title': 'Prompt Tokens', 'type': 'integer'}, 'completion_tokens': {'default': 0, 'title': 'Completion Tokens', 'type': 'integer'}}, 'title': 'Usage', 'type': 'object'}}, 'properties': {'id': {'default': '', 'title': 'Id', 'type': 'string'}, 'choices': {'items': {'$ref': '#/$defs/CompletionResponseChoice'}, 'title': 'Choices', 'type': 'array'}, 'usage': {'allOf': [{'$ref': '#/$defs/Usage'}], 'default': {'prompt_tokens': 0, 'completion_tokens': 0}}}, 'required': ['choices'], 'title': 'MistralModel', 'type': 'object'} >>> chain.print_schema() source: str parent: str name: str version: str etag: str size: int vtype: str location: dict file: File source: str parent: str name: str size: int version: str etag: str is_latest: bool last_modified: datetime location: Union[dict, list[dict], NoneType] vtype: str mistral_response: MistralModel id: str choices: list[CompletionResponseChoice] * list of: CompletionResponseChoice message: MyChatMessage role: str content: str usage: Usage prompt_tokens: int completion_tokens: int

a copy-paste Feature or Pydantic-to-feature

Generating code for user to copy-past is uncommon because it's error prone (depends on environment) and not secure.

It might be better to handle this differently, possibly with a dedicated helper function like pydantic_to_feature().

@volkfox if you think it's an important use case - please share more context. However, it's unlikely should be a part of the data readers.

dmpetrov

@dreadatour great change! Thank you.

A couple comments are inline mostly about the naming.

PS: It seems I didn't clicked Approve button 😅

dmpetrov · 2024-07-11T16:13:13Z

src/datachain/lib/dc.py

@@ -208,6 +208,7 @@ def from_storage(
        catalog: Optional["Catalog"] = None,
        recursive: Optional[bool] = True,
        anon: bool = False,
+        object_name: str = "file",


object_name is a bit too long name. And object never looks good in naming.

how about output or just name?

src/datachain/lib/dc.py

dmpetrov · 2024-07-11T16:16:00Z

src/datachain/lib/dc.py

@@ -208,6 +208,7 @@ def from_storage(
        catalog: Optional["Catalog"] = None,


Could you please replace catalog with session. We shouldn't show catalog to users - only session.

I replaced it but also added kwargs to pass catalog=catalog because it looks like it's not that simple to replace it in tests and probably needs to happen in another PR.

dmpetrov · 2024-07-11T16:16:39Z

src/datachain/lib/dc.py

@@ -208,6 +208,7 @@ def from_storage(
        catalog: Optional["Catalog"] = None,
        recursive: Optional[bool] = True,
        anon: bool = False,


I wish we can move anon to session. and use only session params instead of catalog+anon

It's probably not in this PR.

Dropped it as a named arg but left it possible to pass in kwargs.

src/datachain/lib/dc.py

dmpetrov · 2024-07-11T16:22:14Z

src/datachain/lib/dc.py

@@ -706,6 +663,7 @@ def from_features(
        ds_name: str = "",
        session: Optional[Session] = None,
        output: Union[None, FeatureType, Sequence[str], dict[str, FeatureType]] = None,


we should probably rename output to something like schema or spec and make object_name -> output

Pandas calls it dtype. I'm not sure it's the best name tho.

dmpetrov · 2024-07-11T16:22:52Z

src/datachain/lib/dc.py

+    def from_csv(
+        cls,
+        path,
+        anon: bool = False,
        delimiter: str = ",",
        header: bool = True,
        column_names: Optional[list[str]] = None,
        output: Optional[dict[str, FeatureType]] = None,


The same - schema/spec instead?

dmpetrov · 2024-07-11T16:26:20Z

src/datachain/lib/dc.py

+    def from_csv(
+        cls,
+        path,
+        anon: bool = False,


it would be great to get rid of anon as well. Not sure it belongs to this PR.

dmpetrov · 2024-07-11T18:46:23Z

examples/json-csv-reader.py

    print(static_csv_ds.to_pandas())

    uri = "gs://datachain-demo/laion-aesthetics-csv"
    print()
    print("========================================================================")
    print("dynamic CSV with header schema test parsing 3M objects")
    print("========================================================================")
-    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion", show_schema=True)
+    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion")
+    dynamic_csv_ds.print_schema()


DataChain.from_csv(uri, object_name="csv").schema["csv"]

This seems to be the right approach for examine the schema alongside print_schema() Otherwise, we will need to introduce similar side effects to all parsing methods which explodes API and not considering a good practice.

We can potentially consider improving print_schema() for example by limiting number of outputs like print_schema("csv", "file")

dmpetrov · 2024-07-11T22:46:55Z

examples/json-csv-reader.py

    print(static_csv_ds.to_pandas())

    uri = "gs://datachain-demo/laion-aesthetics-csv"
    print()
    print("========================================================================")
    print("dynamic CSV with header schema test parsing 3M objects")
    print("========================================================================")
-    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion", show_schema=True)
+    dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion")
+    dynamic_csv_ds.print_schema()


a copy-paste Feature or Pydantic-to-feature

Generating code for user to copy-past is uncommon because it's error prone (depends on environment) and not secure.

It might be better to handle this differently, possibly with a dedicated helper function like pydantic_to_feature().

@volkfox if you think it's an important use case - please share more context. However, it's unlikely should be a part of the data readers.

volkfox · 2024-07-11T22:52:48Z

@volkfox <https://github.com/volkfox> if you think it's an important use

case - please share more context. The context is obvious - most datasets carry too many features, so parsing them with a schema is a preferred way to go. OTH, crafting these schemas by hand is a major drawback.

…

On Thu, Jul 11, 2024 at 3:49 PM Dmitry Petrov ***@***.***> wrote: ***@***.**** approved this pull request. @dreadatour <https://github.com/dreadatour> great change! Thank you. A couple comments are inline mostly about the naming. PS: It seems I didn't clicked Approve button 😅 ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -208,6 +208,7 @@ def from_storage( catalog: Optional["Catalog"] = None, recursive: Optional[bool] = True, anon: bool = False, + object_name: str = "file", object_name is a bit too long name. And object never looks good in naming. how about output or just name? ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -218,14 +219,17 @@ def from_storage( type : read file as "binary", "text", or "image" data. Default is "binary". recursive : search recursively for the given path. anon : use anonymous mode to access the storage. + object_name : Generated object column name. How about Created instead of Generated. It might be better to try using Generate name for our generator specifically. ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -208,6 +208,7 @@ def from_storage( catalog: Optional["Catalog"] = None, Could you please replace catalog with session. We shouldn't show catalog to users - only session. ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -208,6 +208,7 @@ def from_storage( catalog: Optional["Catalog"] = None, recursive: Optional[bool] = True, anon: bool = False, I wish we can move anon to session. and use only session params instead of catalog+anon ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > return chain.gen(_func_fr, output=output) @classmethod def from_pandas( # type: ignore[override] - cls, df: "pd.DataFrame", name: str = "", session: Optional[Session] = None + cls, + df: "pd.DataFrame", + name: str = "", + session: Optional[Session] = None, + object_name: Optional[str] = None, It would be great to make it just "str" (without Optional) for consistency with other API calls. ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > def parse_tabular( self, - output: Optional[dict[str, FeatureType]] = None, + output: Union[None, FeatureType, dict[str, FeatureType]] = None, + object_name: Optional[str] = None, same - please get rid of Optional if possible ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -706,6 +663,7 @@ def from_features( ds_name: str = "", session: Optional[Session] = None, output: Union[None, FeatureType, Sequence[str], dict[str, FeatureType]] = None, we should probably rename output to something like schema or spec and make object_name -> output ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > return self.gen(ArrowGenerator(schema, **kwargs), output=output) - def parse_csv( - self, + @classmethod + def from_csv( + cls, + path, + anon: bool = False, delimiter: str = ",", header: bool = True, column_names: Optional[list[str]] = None, output: Optional[dict[str, FeatureType]] = None, The same - schema/spec instead? ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > return self.gen(ArrowGenerator(schema, **kwargs), output=output) - def parse_csv( - self, + @classmethod + def from_csv( + cls, + path, + anon: bool = False, it would be great to get rid of anon as well. Not sure it belongs to this PR. ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -208,6 +208,7 @@ def from_storage( catalog: Optional["Catalog"] = None, recursive: Optional[bool] = True, anon: bool = False, It's probably not in this PR. ------------------------------ In src/datachain/lib/dc.py <#14 (comment)>: > @@ -706,6 +663,7 @@ def from_features( ds_name: str = "", session: Optional[Session] = None, output: Union[None, FeatureType, Sequence[str], dict[str, FeatureType]] = None, Pandas calls it dtype. I'm not sure it's the best name tho. ------------------------------ In examples/json-csv-reader.py <#14 (comment)>: > print(static_csv_ds.to_pandas()) uri = "gs://datachain-demo/laion-aesthetics-csv" print() print("========================================================================") print("dynamic CSV with header schema test parsing 3M objects") print("========================================================================") - dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion", show_schema=True) + dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion") + dynamic_csv_ds.print_schema() DataChain.from_csv(uri, object_name="csv").schema["csv"] This seems to be the right approach for examine the schema alongside print_schema() Otherwise, we will need to introduce similar side effects to all parsing methods which explodes API and not considering a good practice. We can potentially consider improving print_schema() for example by limiting number of outputs like print_schema("csv", "file") ------------------------------ In examples/json-csv-reader.py <#14 (comment)>: > print(static_csv_ds.to_pandas()) uri = "gs://datachain-demo/laion-aesthetics-csv" print() print("========================================================================") print("dynamic CSV with header schema test parsing 3M objects") print("========================================================================") - dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion", show_schema=True) + dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion") + dynamic_csv_ds.print_schema() a copy-paste Feature or Pydantic-to-feature Generating code for user to copy-past is uncommon because it's error prone (depends on environment) and not secure. It might be better to handle this differently, possibly with a dedicated helper function like pydantic_to_feature(). @volkfox <https://github.com/volkfox> if you think it's an important use case - please share more context. However, it's unlikely should be a part of the data readers. — Reply to this email directly, view it on GitHub <#14 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEC4S3RFRBH34YNBTBMCHVDZL4DXNAVCNFSM6AAAAABKXBM3UCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDCNZSGM4TMNBSGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

dmpetrov · 2024-07-12T00:10:44Z

OTH, crafting these schemas by hand is a major drawback.

It looks like we need a dedicated method for this similar to print_schema() but for printing classes like print_features()

dberenbaum · 2024-07-12T15:25:01Z

@dmpetrov Re: output and object_name, I agree the names are not ideal, but want to provide more context for why it's this way in the PR before deciding on the final api:

output argument is to be consistent with output in map/gen/agg/batch_map and is treated identical to those args (with one minor difference that those support Sequence[str], although I am not sure that is actually working or makes sense to keep). Do we want to rename in those also and make it consistent across the api?
object_name was taken from from_json, which already has args spec, schema_from, object_name, and model_name, so we need an arg name that works there. It might also be worth considering adding the arg to map/gen/agg/batch_map in addition to/instead of signal map since it does the same thing. Also, I think we need to establish some terminology for what this is so we can name it. Is it an object, signal, feature, output, or something else?
If we make object_name required, we make it impossible to have a "flat" table with more typical column names that people expect. It's also different from map/gen/agg/batch_map where a grouped signal name is optional.

This reverts commit 4ca848f.

volkfox · 2024-07-12T18:22:43Z

@dberenbaum we also should include the model_name argument in the signature.
The reason is that you might want to have different objects with a same schema pointing to the same model. For example you are reading two annotation variants of the same schema, from CSV1 and CSV2. You want the resulting objects to have different names but the model to be named identically.

Unrelated to this issue but a good idea - have the n_rows argument which would enable optimization for code like :

DataChain.from_csv(uri).limit(5).show()

not to process 3 million rows to extract 5.

volkfox · 2024-07-12T18:41:36Z

src/datachain/lib/dc.py

                output = schema_to_output(schema)
            except ValueError as e:
                raise DatasetPrepareError(self.name, e) from e

+        if object_name:
+            if isinstance(output, dict):
+                output = dict_to_feature(object_name, output)


It is not always that you want a Feature class name to be the same as the object name.

This is why from_json() also has model_name argument

One more note on the proposed change:

It would be great to have some way to mark the fields of the auto-schema as 'Optional'
Without this, the last example from the test set examples/json-csv-reader.py will fail at first reference:

from datachain.lib.dc import C, DataChain uri = "gs://datachain-demo/laion-aesthetics-csv" print() print("========================================================================") print("dynamic CSV with header schema test parsing 3M objects") print("========================================================================") dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion") dynamic_csv_ds.collect()

dynamic_csv_ds = DataChain.from_csv(uri, object_name="laion")
Processed: 1 rows [00:00, 1088.02 rows/s]
dynamic_csv_ds.collect()
Processed: 1 rows [00:00, 1221.05 rows/s]
Processed: 1 rows [01:57, 117.96s/ rows]
Generated: 3303469 rows [01:57, 28004.44 rows/s]
Traceback (most recent call last):
File "", line 1, in
File "/Users/dkh/datachain/src/datachain/lib/dc.py", line 544, in collect
return list(self.iterate(*cols))
File "/Users/dkh/datachain/src/datachain/lib/dc.py", line 537, in iterate
yield chain.signals_schema.row_to_features(row, chain.session.catalog)
File "/Users/dkh/datachain/src/datachain/lib/signal_schema.py", line 189, in row_to_features
obj = fr_cls(**json)
File "/Users/dkh/datachain/venv/datachain/lib/python3.9/site-packages/pydantic/main.py", line 193, in init
self.pydantic_validator.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 1 validation error for laion
pwatermark
Input should be a valid number [type=float_type, input_value=None, input_type=NoneType]
For further information visit https://errors.pydantic.dev/2.8/v/float_type

dmpetrov · 2024-07-13T05:46:46Z

(with one minor difference that those support Sequence[str], although I am not sure that is actually working or makes sense to keep)

Yeah. It was introduced for tuples that are flattened (def func(file) -> tuple[int, int, str]:) which is similar use case. So, clear similarity with output

2. adding the arg to map/gen/agg/batch_map in addition to/instead of signal map since it does the same thing. Also, I think we need to establish some terminology for what this is so we can name it.

Right, it feels like a lack of terminology and unification! SignalSchema seems like a right data structure. The problem is, it was not designed for user-facing APIs. But it can be dome with simple tricks: making it a child of dict (no .values) and start accepting Sequence[str]. User still should not see it tho - just passing Sequence[str].
If we go this road, output here will have similar meaning as in map() and such.

WDYT?

3. If we make object_name required ...

💯
My idea was using empty string as a default value (for flattening).

@dberenbaum we also should include the model_name argument in the signature.

It makes sense. @dberenbaum WDYT?

PS: @dberenbaum please do not wait long for all the design decisions - we can redesign on top of this.

codecov · 2024-07-15T15:41:20Z

The author of this PR, dberenbaum, is not an activated member of this organization on Codecov.
Please activate this user on Codecov to display this PR comment.
Coverage data is still being uploaded to Codecov.io for purposes of overall coverage calculations.
Please don't hesitate to email us at [email protected] with any questions.

dberenbaum · 2024-07-15T17:08:01Z

Right, it feels like a lack of terminology and unification! SignalSchema seems like a right data structure. The problem is, it was not designed for user-facing APIs. But it can be dome with simple tricks: making it a child of dict (no .values) and start accepting Sequence[str]. User still should not see it tho - just passing Sequence[str]. If we go this road, output here will have similar meaning as in map() and such.

WDYT?

Sequence[str] is supported in the latest update. I think it makes sense to keep the separation between the user-facing arg and the SignalSchema data structure. Not sure how it would work to pass something like Sequence[str] directly to SignalSchema since it will need data types, but let me know if I'm misunderstanding you.

@dberenbaum we also should include the model_name argument in the signature.

It makes sense. @dberenbaum WDYT?

Added it to unblock and move forward here. TBH I'm not sure this should be exposed to the user, and this goes back to the discussion above about whether we should print pydantic schemas or provide an editable dict-like schema.

It would be great to have some way to mark the fields of the auto-schema as 'Optional'
Without this, the last example from the test set examples/json-csv-reader.py will fail at first reference:

Yes, this seems like it's the same issue as https://github.com/iterative/dvcx/issues/1697, so let's follow up there.

PS: @dberenbaum please do not wait long for all the design decisions - we can redesign on top of this.

Yup, I'm merging and we can follow up on these questions and how to name these args.

Resolved

* support object_name in all from_ formats * refactor arrow infer schema * use session instead of catalog in datachain * fix tests * Revert "fix tests" This reverts commit 4ca848f. * hide anon arg in datachain * drop optional from object_name * accept list of col names * fix csv col names and add model_name

support object_name in all from_ formats

2483f73

dberenbaum requested review from dmpetrov and volkfox July 11, 2024 13:55

dberenbaum commented Jul 11, 2024

View reviewed changes

dberenbaum changed the title ~~Support object_name in all from_ formats~~ Support object_name in all from_ formats Jul 11, 2024

volkfox reviewed Jul 11, 2024

View reviewed changes

dmpetrov approved these changes Jul 11, 2024

View reviewed changes

refactor arrow infer schema

a81d9f4

Dave Berenbaum added 5 commits July 12, 2024 11:25

use session instead of catalog in datachain

23cd527

merge main

7ec3fb3

fix tests

4ca848f

Revert "fix tests"

d39eb29

This reverts commit 4ca848f.

hide anon arg in datachain

d236203

volkfox self-requested a review July 12, 2024 18:37

volkfox previously requested changes Jul 12, 2024

View reviewed changes

Dave Berenbaum added 2 commits July 15, 2024 09:54

drop optional from object_name

a2a37c7

Merge branch 'main' into unify_from_formats

a1f9c93

dberenbaum force-pushed the unify_from_formats branch from aa27b4b to a1f9c93 Compare July 15, 2024 13:55

Dave Berenbaum added 2 commits July 15, 2024 11:22

accept list of col names

9663279

Merge branch 'main' into unify_from_formats

4349b6e

fix csv col names and add model_name

1f4d798

dberenbaum requested a review from volkfox July 15, 2024 17:08

dberenbaum merged commit 3aa4031 into main Jul 15, 2024
12 checks passed

dberenbaum deleted the unify_from_formats branch July 15, 2024 17:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support `object_name` in all `from_` formats #14

Support `object_name` in all `from_` formats #14

dberenbaum commented Jul 11, 2024

dberenbaum Jul 11, 2024

volkfox Jul 11, 2024

dberenbaum Jul 11, 2024

volkfox Jul 11, 2024

dberenbaum Jul 11, 2024

volkfox Jul 11, 2024

dberenbaum Jul 11, 2024

dmpetrov Jul 11, 2024

volkfox Jul 11, 2024

dmpetrov Jul 11, 2024

dmpetrov left a comment

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dberenbaum Jul 12, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dberenbaum Jul 12, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

dmpetrov Jul 11, 2024

volkfox commented Jul 11, 2024 via email

dmpetrov commented Jul 12, 2024

dberenbaum commented Jul 12, 2024

volkfox commented Jul 12, 2024

volkfox Jul 12, 2024

volkfox Jul 12, 2024

dmpetrov commented Jul 13, 2024 •

edited

Loading

codecov bot commented Jul 15, 2024

dberenbaum commented Jul 15, 2024

		@@ -208,6 +208,7 @@ def from_storage(
		catalog: Optional["Catalog"] = None,

Support object_name in all from_ formats #14

Support object_name in all from_ formats #14

Conversation

dberenbaum commented Jul 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dmpetrov left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

volkfox commented Jul 11, 2024 via email

dmpetrov commented Jul 12, 2024

dberenbaum commented Jul 12, 2024

volkfox commented Jul 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dmpetrov commented Jul 13, 2024 • edited Loading

codecov bot commented Jul 15, 2024

dberenbaum commented Jul 15, 2024

Support `object_name` in all `from_` formats #14

Support `object_name` in all `from_` formats #14

dmpetrov commented Jul 13, 2024 •

edited

Loading