Opened an issue for write_lance
# daft-dev
e
Opened an issue for write_lance
j
Thanks! What kind of use-case are you using Lance for?
cc @Cory Grinstead here as well
e
Embedding colocation with payload data. We are implementing Lance persistence first before iceberg given its search and indexing capabilities. I also noticed that write_lance isn't present in the docs. Should I make another issue for that?
j
Even better you could make a contribution 😉
🙌 1
Check out our /docs folder it should be pretty easy to add it to the appropriate rst!
e
ok!
I'll give it a try
j
Lmk if you need help
👍 1
e
Would you recommend I fork daft or just create a new branch
Still very much a noob to contributing
j
It’s pretty ez! 1. Fork the repo 2. Make a change, push it to a branch on your fork 3. Make a PR against the main repo from your fork (you can use the Github UI)
👍 1
e
Ok cool, thank you!
j
It’s just an additional option in
New Pull Request
— you know how they usually have an option like target branch etc? There will be another option for target repository… Just select the main Eventual-Inc one
Welcome! Looking forward to the contrib 🙂
c
@Everett Kleven, I think there was a bit of a misunderstanding of how the
write_lance
query gets executed. I replied on the GH issue. TLDR: we're already using
.to_arrow()
for the write lance operation. The current approach was recommended & reviewed by one of the lancedb core contributors https://github.com/Eventual-Inc/Daft/pull/2421
🙌 1
👍 1
e
Thanks @Cory Grinstead ! I definitely was caught up on write_df's contents. Looks like the return type from
lance.fragments.write_fragments()
is the FragmentMetadata class, which is a catch all for all fragment submodule methods