lakeFS 1.0 - Code Migration Guide
Version 1.0.0 promises API and SDK stability. By “API” we mean any access to a lakeFS REST endpoint. By “SDK” we mean auto-generated lakeFS clients: lakefs-sdk
for Python and io.lakefs:sdk
for Java. This guide details the steps to allow you to upgrade your code to enjoy this stability.
Avoid using APIs and SDKs labeled as experimental
, internal
, or deprecated
. If you must use them, be prepared to adjust your application to align with any lakeFS server updates.
Your software developed without such APIs should be compatible with all minor version updates of the lakeFS server from the version you originally developed with.
If you rely on a publicly released API and SDK, it will adhere to semantic versioning. Transitioning your application to a minor SDK version update should be smooth.
The operation names and tags from the api/swagger.yml
specification might differ based on the SDK or coding language in use.
Deleted API Operations
The following API operations have been removed:
updatePassword
forgotPassword
logBranchCommits
expandTemplate
createMetaRange
ingestRange
updateBranchToken
Internal API Operations
The following operations are for internal
use only and should not be used in your application code. Some deprecated operations have alternatives provided.
setupCommPrefs
getSetupState
setup
getAuthCapabilities
uploadObjectPreflight
setGarbageCollectionRulesPreflight
createBranchProtectionRulePreflight
postStatsEvents
dumpRefs
(will be replaced with a long-running API later)restoreRefs
(will be replaced with a long-running API later)createSymlinkFile
(Deprecated)getStorageConfig
(Deprecated. Alternative:getConfig
)getLakeFSVersion
(Deprecated. Alternative:getConfig
)stageObject
(Deprecated. Alternatives:get/link physical address
orimport
)internalDeleteBranchProtectionRule
(Deprecated. Temporary backward support. Alternative:setBranchProtectionRules
)internalCreateBranchProtectionRule
(Deprecated. Temporary backward support. Alternative:setBranchProtectionRules
)internalGetBranchProtectionRule
(Deprecated. Temporary backward support. Alternative:getBranchProtectionRules
)internalDeleteGarbageCollectionRules
(Deprecated. Temporary backward support. Alternative:deleteGCRules
)internalSetGarbageCollectionRules
(Deprecated. Temporary backward support. Alternative:setGCRules
)internalGetGarbageCollectionRules
(Deprecated. Temporary backward support. Alternative:getGCRules
)prepareGarbageCollectionCommits
getGarbageCollectionConfig
New/Updated API Operations
Here are the newly added or updated operations:
getConfig
(Retrieve lakeFS version and storage info)setBranchProtectionRules
(Route updated)getBranchProtectionRules
(Route updated)getGCRules
(New route introduced)setGCRules
(New route introduced)deleteGCRules
(New route introduced)importStatus
(Response structure updated: ‘ImportStatusResp’ to ‘ImportStatus’)uploadObject
(Parameters ‘if-none-match’ and ‘storageClass’ are now deprecated)prepareGarbageCollectionCommits
(Request body removed)getOtfDiffs
&otfDiff
(Removed from ‘otf diff’ tag; retained in ‘experimental’ tag)
Migrating SDK Code for Java and JVM-based Languages
Introduction
If you are using the lakeFS client for Java or for any other JVM-based language, be aware that the current package is not stable with respect to minor version upgrades. Transitioning from io.lakefs:lakefs-client
to io.lakefs:sdk
will necessitate rewriting your API calls to fit the new design paradigm.
Problem with the Old Style
Previously, API calls required developers to pass all parameters, including optional ones, in a single function call. As demonstrated in this older style:
ObjectStats objectStat = objectsApi.statObject(
objectLoc.getRepository(), objectLoc.getRef(), objectLoc.getPath(),
false, false);
This method posed a couple of challenges:
- Inflexibility with Upgrades: If an optional parameter were introduced in newer versions, existing code would fail to compile.
- Maintenance Difficulty: Long argument lists can be challenging to manage and understand, leading to potential mistakes and readability issues.
Adopting the Fluent Style
In the revised SDK, API calls adopt a fluent style, making the code more modular and adaptive to changes.
Here’s an example of the new style:
ObjectStats objectStat = objectsApi
.statObject(
objectLoc.getRepository(), objectLoc.getRef(), objectLoc.getPath()
)
.userMetadata(true)
.execute();
Here’s a breakdown of the changes:
- Initial Function Call: Begin by invoking the desired function with all required parameters.
- Modifying Optional Parameters: Chain any modifications to optional parameters after the initial function. For instance,
userMetadata
is changed in the example above. - Unused Optional Parameters: You can safely ignore these. For instance, this code ignores the
presign
optional parameter because it never uses it. - Execution: Complete the call with the
.execute()
method.
This new design offers several advantages:
- Compatibility with Upgrades: When a new optional parameter is introduced, existing code will use its default value, preserving compatibility with minor server version upgrades.
- Improved Readability: The fluent style makes it evident which parameters are required and which ones are optional, enhancing code clarity.
When migrating your code, ensure you refactor all your API calls to adopt the new fluent style. This ensures that your application remains maintainable and is safeguarded against potential issues arising from minor SDK version upgrades.
For an illustrative example of the transition between styles, you can view the changes made in this pull request: lakeFS pull request #6529.
Migrating SDK Code for Python
Introduction
If you are using the lakeFS client for Python, be aware that the current package is not stable with respect to minor version upgrades. Transitioning from lakefs-client
to lakefs-sdk
will necessitate rewriting your API calls.
Here’s a breakdown of the changes:
- Modules change
- The previous
model
module was renamed tomodels
, meaning thatlakefs_client.model
imports should be replaced withlakefs_sdk.models
imports. - The
apis
module inlakefs_client
is deprecated and no longer supported. To migrate to the newapi
module inlakefs_sdk
, you should replace all imports oflakefs_client.apis
with imports oflakefs_sdk.api
. We still recommend using thelakefs_sdk.LakeFSClient
class instead of using theapi
module directly. TheLakeFSClient
class provides a higher-level interface to the LakeFS API and makes it easier to use LakeFS in your applications.
- The previous
upload_object
API call: Thecontent
parameter value passed to theobjects_api.upload_object
method call should be either astring
containing the path to the uploaded file, orbytes
of data to be uploaded.get_object
API call: The return value ofclient.get_object(...)
is abytearray
containing the content of the object.**client.{operation}_api**
: Thelakefs-client
package’sLakeFSClient
class’s deprecation-marked operations (client.{operation}
) will no longer be available in thelakefs-sdk
package’sLakeFSClient
class. In their place, theclient.{operation}_api
should be used.- Minimum Python Version: 3.7
- Fetching results from response objects: Instead of fetching the required results properties from a dictionary using
response_result.get_property(prop_name)
, the response objects will include domain specific entities, thus referring to the properties in theresults
of the response -response_result.prop_name
. For example, instead of:
response = lakefs_client.branches.diff_branch(repository='repo', branch='main')
diff = response.results[0] # 'results' is a 'DiffList' object
path = diff.get_property('path') # 'diff' is a dictionary
You should use:
response = lakefs_client.branches_api.diff_branch(repository='repo', branch='main')
diff = response.results[0] # 'results' is a 'DiffList' object
path = diff.path # 'diff' is a 'Diff' object