在 Vue 中,当你将一个布尔对象双向绑定到 radio 输入上时,确保 radio 的 value 属性仍然保持布尔类型是很重要的。如果 value 属性是字符串,那么 Vue 会将其解释为字符串而不是布尔值。以下是一个示例,演示如何正确地将布尔对象双向绑定到 radio 按钮,并确保 value 属性保持布尔类型:
<template>
<div>
<input type="radio" v-model="myBoolean" :value="true" /> True
<input type="radio" v-model="myBoolean" :value="false" /> False
<p>myBoolean: {{ myBoolean }}</p>
</div>
</template>
<script>
export default {
data() {
return {
myBoolean: false, // 布尔对象
};
},
};
</script>
在这个示例中,我们使用了 v-model 指令将 myBoolean 属性与两个 radio 按钮进行了双向绑定。通过将 value 属性设置为 true 和 false,我们确保了 myBoolean 属性保持布尔类型。
这样,当用户选择其中一个 radio 按钮时,myBoolean 属性将保持布尔值而不是字符串。确保 value 属性的类型与要绑定的数据类型匹配,以确保绑定的数据类型保持一致。
同样的问题出现在 select 上也是一样:
<select v-model="cat.colorId" required>
<option :value="null">不选择</option>
<option v-for="color in colors" :value="color.id">{{color.name}}</option>
</select>
在数据库连接字符串可设置是否将 tinyint(1) 映射为 bool,否则为 sbyte:
TreatTinyAsBoolean=false/true
tinyint(1) 一般用于表示 bool 型字段,存储内容为 0 或 1,但有时候也用来存储其它数字。
以 Discuz! 的表 pre_forum_post 为例,字段 first 和 invisible 都是 tinyint(1),但 first 只储存 0 和 1,invisible 却有 -1、-5 之类的值。
因此我们一般设置 TreatTinyAsBoolean=false,程序中 first 与 invisible 均以 sbyte 处理。
设置 TreatTinyAsBoolean=true 后,EF 或 EF Core 自动将该类型映射为 bool,方便在程序中作进一步处理。
一旦设置 TreatTinyAsBoolean=true,那么所有查询结果中 tinyint(1) 字段的返回值永远只有 1 和 0(即 True/False),即使真实值为 -1,也返回 1。
因为我们必须在确保所有的 tinyint(1) 类型字段都仅表示布尔值是才设置 TreatTinyAsBoolean=true。
一旦部分 tinyint(1) 类型字段用于存放 0 和 1 以外的数,那么就应该设置 TreatTinyAsBoolean=false。
在数据库优先的项目中,以 TreatTinyAsBoolean=false 生成数据模型后,可将明确为布尔类型的字段改为 bool。列出 MySQL 数据库中所有表所有字段中类型为 tinyint(1) 的字段值
以 .edmx 为例:
在项目中搜索该字段名,在搜索结果中找到 .edmx 文件中的两处。
.edmx 文件中的注释已经表明其包含 SSDL、CSDL、C-S mapping 三块内容,
在 SSDL content 下方找到该字段:
<Property Name="字段名" Type="tinyint" Nullable="***" />
改为
<Property Name="字段名" Type="bool" Nullable="***" />
在 CSDL content 下方找到该属性:
<Property Name="属性名" Type="SByte" Nullable="***" />
改为
<Property Name="属性名" Type="Boolean" Nullable="***" />
在解决方案管理器中展开 .edmx ->库名.tt -> 表名.cs 文件,
将模型类中的属性
public sbyte invisible { get; set; }
改为
public bool invisible { get; set; }
或 sbyte? 改为 bool?。
在 EF Core 中,直接打开对应数据表的 .cs 文件,更改属性类型即可。
相关报错:
错误: 指定的成员映射无效。类型中的成员的类型“Edm.SByte[Nullable=False,DefaultValue=]”与类型中的成员的“MySql.bool[Nullable=False,DefaultValue=]”不兼容。
InvalidOperationException: The property '***' is of type 'sbyte' which is not supported by the current database provider. Either change the property CLR type, or ignore the property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.
尝试先连接一次能解决此问题(概率),非常的莫名其妙:
using Data.Discuz.db_bbs2021Context dbd = new();
var conn = dbd.Database.GetDbConnection();
conn.Open();
conn.Close();
参考:
https://mysqlconnector.net/connection-options/
https://stackoverflow.com/questions/6656511/treat-tiny-as-boolean-and-entity-framework-4
2023年1月注:本文适用于 Pomelo.EntityFrameworkCore.MySql 6.0,升级到 7.0 后会出现:
System.InvalidOperationException:“The 'sbyte' property could not be mapped to the database type 'tinyint(1)' because the database provider does not support mapping 'sbyte' properties to 'tinyint(1)' columns. Consider mapping to a different database type or converting the property value to a type supported by the database using a value converter. See https://aka.ms/efcore-docs-value-converters for more information. Alternately, exclude the property from the model using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.”
当 MySQL 中使用 tinyint(1) 作为布尔值类型时,ASP.NET Core DBFirst 创建模型时会将其定义为 sbyte,运行时会抛出异常:
InvalidCastException: Unable to cast object of type 'System.Boolean' to type 'System.SByte'.
我们可以在数据库连接字符串中加入 TreatTinyAsBoolean=false 来实现不抛出异常,但程序中赋值和判断该字段时还是会比较麻烦。
因此我更倾向于将数据库中该字段类型改为 bit(1)。
2019.11.28 注:这回遇到 tinyint(1) 映射到了 C# 的 bool,而 bit(1) 却映射到了 ulong。具体什么原因未作排查,反正哪个最终为 bool 就选哪个吧。
百度地图 | 天地图 | |
初始化地图 | var map = new BMap.Map("allmap"); | var map = new T.Map("allmap"); |
将覆盖物添加到地图 | addOverlay(overlay: Overlay) | addOverLay(overlay:OverLay) |
从 Map 的 click 事件中获取坐标点 | map.addEventListener("click", function (e) { Point = e.point; } | map.addEventListener("click", function (e) { LngLat = e.lnglat; } |
坐标点 | new BMap.Point(lng: Number, lat: Number) | new T.LngLat(lng: Numbe, lat: Number) |
像素点 | new BMap.Pixel(x: Number, y: Number) | new T.Point(x: Number, y: Number) |
文本标注 |
|
|
设置文本标注样式 | setStyle(styles: Object) | 每个样式使用单独的 set 方法实现 |
图像标注 |
|
|
为图像标注添加文本标注 | Marker.setLabel(label: Label) | 无。 可借用 title(鼠标掠过显示)属性来实现,并通过 Marker.options.title 来获取值 |
从图像标注获取坐标点 | Point = Marker.getPosition(); | LngLat = Marker.getLngLat(); |
绘制折线 |
|
|
绘制多边形 |
|
|
设置多边形的点数组 | Polygon.setPath(points: Array<Point>) | Polyline.setLngLats(lnglats: Array<LngLat>) |
设置地图视野 | Map.setViewport(view: Array<Point> | Viewport, viewportOptions: ViewportOptions) | Map.setViewport(view: Array<LngLat>) |
工作这几年碰到的版本检测升级的接口也算是五花八门,啥样的都有,但肯定有的功能是有个 apk 的下载链接,能间接或直接提示你是强制还是非强制更新:
间接是指提供你后台最新版本号,让你自己与本地版本号通过比较得出是否升级;
直接就是后台接口直接返回个 Boolean 类型告诉你是强制或者非强制更新。
个人认为一个好的版本检测接口需要设计的更灵活更清晰用起来更方便,下面就我理解的接口设计如下(如思路有误,欢迎指正):
总字段如下(并不是所有字段都要返回给客户端):
1.最新版本号 :newVersion
2.最小支持版本号 : minVersion
3.apk 下载 url : apkUrl
4.更新文案 : updateDescription
5.是否有更新 : isUpdate
6.是否强制更新 : forceUpdate 可选字段:
7.apk 文件大小:apkSize
8.apk 的文件 MD5 值:md5
方案一(后端处理逻辑):
在客户端请求参数中添加当前版本号 currentVersion 传输给后台,由后台根据客户端传过来的当前版本号 currentVersion 做相应的判断后给出是否强制更新。
后端逻辑如下:
如果 currentVersion < newVersion, 则 isUpdate = true;
如果 currentVersion < minVersion, 则 forceUpdate = true;
如果 currentVersion >= minVersion, 则 forceUpdate = false;
如果有特殊需求可指定某个版本必须强制更新,如 currentVersion == XXX, 则 forceUpdate = true;
如果 currentVersion == newVersion,则 isUpdate = false.
结论:
返回客户端的字段仅需要 apk 下载 url : apkUrl
、更新文案 : updateDescription
、是否有更新 : isUpdate
、 是否强制更新 : forceUpdate
这四个字段即可。
方案二(前端处理逻辑):
逻辑和后端处理逻辑大体上一致,只是把逻辑判断移到前台,故需要后端提供最新版本号 :newVersion
、 最小支持版本号 : minVersion
、apk下载url : apkUrl
、更新文案 : updateDescription
这四个字段。
客户端逻辑如下:
如果 currentVersion < newVersion, 则有更新信息;
如果 currentVersion < minVersion, 则需要强制更新;
如果 currentVersion >= minVersion, 则不需要强制更新;
如果 currentVersion == newVersion,则没有更新信息。
总结:
细心的你可能会发现上面的可选字段 apkSize 和 md5 并没有用到,既然是可选字段也就是可用可不用,根据需要决定是否采用,这里来讲下他们的用处。
apk 文件大小 apkSize
这个用处可以说出于考虑用户体验,需要在升级弹框出来展示给用户将要更新的内容多大,让用户决定在非 WIFI 状态是否要更新,不能为了拉用户下载量或所谓的 UV 数直接让用户在不知道大小的情况下去直接下载(土豪用户绕路)
。apk 的文件 MD5 值
这个主要是出于安全考虑吧,因为文件内容固定的话对应的 md5 是一样的,我们可以通过这个 md5 值来和下载的 apk 的 md5 值进行比较去保证我们从服务器更新下载的 apk 是一个完整的未被篡改的安装包,也就是说如果我们下载的 apk 的 md5 值和服务器返回的 md5 值相等,则说明我们下载的 apk 是完整的,且没有被相关有心人处理过的 apk。
综上所述,这个版本更新的处理逻辑客户端和后端谁来做都可以,无关乎懒不懒的问题,个人感觉灵活性后端比客户端方便多了,毕竟后端可以指定 minVersion 与 newVersion 中间的任意一个版本强制更新,而客户端做起来就没有那么灵活了,个人见解,如有更好的方案,欢迎指教。