django使用uuid作为主键的坑、问题记录
问题一 model设置问题
两个例子
例子一:
models.CharField(max_length=10,default=uuid.uuid4,editable=False, primary_key=True)
例子二:
models.UUIDField(max_length=10,default=uuid.uuid4,editable=False, primary_key=True)
这里我使用的是例子一,使用例子二发现生成的uuid不符合django中path里面uuid的规范,导致path识别不到,非常坑,下面是我问gpt的一些回答,我这里总结一下:①uuid的规范是中间有几个横杆的;②使用UUIDField可以减少字符串和UUID之间数据类型的切换,提高性能;③使用UUIDField可以使用数据库里面的一些操作,而使用CharField+uuid.uuid4来实现就会比较直接,但是里面会涉及到UUID和字符串之间的转换。
GPT:
一种是使用models.CharField并在其中使用uuid.uuid4作为默认值,另一种是直接使用models.UUIDField。这两种方法生成UUID的方式是不同的,原因如下:
字段类型的差异:
models.CharField:这是一个字符字段,用于存储字符串。在您的方法中,UUID被转换为字符串存储。
models.UUIDField:这是一个专门用于存储UUID的字段。它确保UUID始终以正确的格式(通常是32个字符长,例如:123e4567-e89b-12d3-a456-426655440000)存储。
默认值的差异:
使用uuid.uuid4()生成新的UUID。每次您运行数据库迁移或创建新的数据库记录时,都会生成一个新的UUID。
models.UUIDField的默认值通常是None,除非您明确为其指定一个值。
性能和存储的差异:
使用models.CharField,UUID被存储为字符串。这可能会稍微增加存储需求,并可能在某些操作中略微降低性能,因为需要进行字符串到UUID的转换。
models.UUIDField直接存储UUID,通常更为高效。
功能和灵活性的差异:
models.UUIDField提供了更多的内置功能和验证,例如自动的UUID版本检查(例如,确保UUID是V4格式)。
使用models.CharField和uuid.uuid4可能不会提供这些内置功能。
数据库级别的约束:
在某些数据库系统中,字符串字段和UUID字段可能有不同的性能特性或索引选项。虽然Django隐藏了这些底层细节,但了解这些差异可以帮助您更好地优化数据库性能。
与Python 3.8+版本的兼容性:
从Python 3.8开始,您可以直接在字段类型中定义默认的函数调用,如您的例子所示。这意味着当您迁移模型时,Django可以自动为您调用uuid.uuid4()。但使用models.UUIDField,您仍然需要显式地生成和设置UUID。
基于上述差异,如果您的应用场景需要专门处理和验证UUID、追求最佳性能和利用数据库功能,那么使用models.UUIDField可能是更好的选择。如果您只是需要一个唯一的标识符,并且不关心UUID的具体格式或验证,那么使用models.CharField和uuid.uuid4作为默认值可能更简单、更直接。
#
问题二 path默认最后加入’/’
如果你上面没有解决,试试这个
paht("xxxx/<uuid:pk>/",xxxViewSet.as_view())