mirror of
https://gitee.com/milvus-io/milvus.git
synced 2026-01-07 19:31:51 +08:00
cd931a0388
issue: #43427 pr: #37417 This pr's main goal is merge #37417 to milvus 2.5 without conflicts. # Main Goals 1. Create and describe collections with geospatial type 2. Insert geospatial data into the insert binlog 3. Load segments containing geospatial data into memory 4. Enable query and search can display geospatial data 5. Support using GIS funtions like ST_EQUALS in query # Solution 1. **Add Type**: Modify the Milvus core by adding a Geospatial type in both the C++ and Go code layers, defining the Geospatial data structure and the corresponding interfaces. 2. **Dependency Libraries**: Introduce necessary geospatial data processing libraries. In the C++ source code, use Conan package management to include the GDAL library. In the Go source code, add the go-geom library to the go.mod file. 3. **Protocol Interface**: Revise the Milvus protocol to provide mechanisms for Geospatial message serialization and deserialization. 4. **Data Pipeline**: Facilitate interaction between the client and proxy using the WKT format for geospatial data. The proxy will convert all data into WKB format for downstream processing, providing column data interfaces, segment encapsulation, segment loading, payload writing, and cache block management. 5. **Query Operators**: Implement simple display and support for filter queries. Initially, focus on filtering based on spatial relationships for a single column of geospatial literal values, providing parsing and execution for query expressions.Now only support brutal search 6. **Client Modification**: Enable the client to handle user input for geospatial data and facilitate end-to-end testing.Check the modification in pymilvus. --------- Signed-off-by: Yinwei Li <yinwei.li@zilliz.com> Signed-off-by: Cai Zhang <cai.zhang@zilliz.com> Co-authored-by: cai.zhang <cai.zhang@zilliz.com>
Integration test
This folder contains the integration test for Milvus components.
How to run integration test locally
Integration test still need some thirdparty components to start:
cd [milvus-folder]/deployments/docker/dev && docker compose up -d
Run following script to start the full integration test:
cd [milvus-folder]
make milvus # milvus needs to be compiled to make cpp build ready
./scripts/run_intergration_test.sh
If you want to run single test case, you could execute command like this example
# mq, etcd, minio ready before
cd [milvus-folder]
source scripts/setenv.sh
cd tests/integration/[testcase-folder]/
go test -run "$testCaseName^" -testify.m "$subTestifyCaseName^" -race -v
Recommended coding style for add new cases
Using suite
MiniClusterandMiniClusterSuite` provides lots of comment preset tool function to execute intergration test.
It is recommend to add a new test with testify/suite
import (
// ...
"github.com/milvus-io/milvus/tests/integration"
)
type NewSuite struct {
integration.MiniClusterSuite
}
// Setups and teardowns, optional if no custom logic needed
// example to suite setup & teardown, same logic applies to test setup&teardown
func (s *NewSuite) SetupSuite() {
s.MiniClusterSuite.SetupSuite()
// customized setup
}
func (s *NewSuite) TearDownSuite() {
s.MiniClusterSuite.TearDownSuite()
// customized teardown
}
New folder for each new scenario
It's a known issue that integration test cases run in same process might affect due to some singleton component not fully cleaned.
As a temp solution, test cases are separated into different packages to run independently.