The convention for how to name the default LaminDB instance object

[falexwolf]

Coming from lamindb, you’d expect the object to be called ln.

Not knowing about lamindb makes db more natural.

The thing that db doesn't convey is that "you can only have one default instance".

What do you guys think this should be called? This is a very fundamental question that we should resolve quickly.

Here is how the Quickstart would look using the ln namespace.

install.packages("laminr")  # install the R package
library(laminr)

ln <- connect()
ln$track()  # soon
artifact <- ln$Artifact$get("KBW89Mf7IGcekja2hADu")
adata <- artifact$load() # load the dataset into memory

# work with the dataset

ln$Artifact("./my_result_folder", description="My result").save()
ln$finish()  # soon

[lazappi]

Is it that you want to be consistent in examples or is there another reason you think it's important?

I guess the difference is that in Python ln represents the while lamindb module whereas in R what we have been calling db is an object representing the interface to a specific database instance and there are/could be parts of the package that exist outside that object. I would say that db is probably clearer but ln is more consistent with Python. Also, R doesn't have the same convention of shortening package names to two letter codes.

I don't really have an open either way.

[rcannood]

Second what Luke just said.

Is this issue mostly about how lamindb usage is documented?

The thing that db doesn't convey is that "you can only have one default instance".

This is a limitation I still don't understand, though 😅 I get why you might want users to have a default instance of ease of use, but restricting them to interacting with only one instance is limiting lamindb's potential IMO.

[falexwolf]

Thanks for commenting, guys!

Let me re-phrase: will in your opinion db convey better that the default instance object is different from all other instance objects the user might create? Or will ln convey that better?

The consistency aspect with Python is also important because people will see Python and R code side by side in the docs through the language tabs. But I'd say it's more important that it feels reasonable to an R user.

To your question, Robrecht: the point is that within one user session, write operations should only be done on the default instance, in particular write operations for data lineage tracking; but because other writes need lineage this also holds for other writes. Without this constraint, you'd need to handle parallel user session across database instances which would make things incredibly complicated.

You can read data from as many instances as you want during a session; all of this data flows into the current default instance.

It's a bit similar to working with git: you always only work in one repository at a time where you track changes even if you're pulling in code from many other sources.

[falexwolf]

I think it'd make sense to call the object that represents CellXGene cxg.

Hence,

ln <- connect()
ln$track()
cxg <- connect("laminlabs/cellxgene")

Or

db <- connect()
db$track()
cxg <- connect("laminlabs/cellxgene")

PS: The R QuickStart is now at the top of the landing page. Maybe it should also already do a cross-instance transfer 🤔

[falexwolf]

OK, it seems like we agreed on db.