内容提供者中的 Content_URI
据我了解，Content Provider是访问数据库内容的一种手段。
为了访问数据库，需要Authority部分。该权限部分由 CONTENT_URI 提供。 因此Content_URI是向数据库授予权限的一种手段。 就 CONTENT_URI 而言，它通常采用以下形式
content://com.example.transportationprovider/trains/122
______ |____________________________________|_____ |___
A B C D
Where A = Content,
B = Authority Part
c = Path determining what data to request
D = specific data
上面的场景是一个理想的场景，其中我们传递 /trains 作为唯一的数据库名称。 但是，如果我有以下 content_uri：
content://com.example.transportationprovider/land/bus/133
在这种情况下，/land/bus 是路径段。
那么这些数据在内部是如何存储在数据库中的呢？ 或者内容提供商如何解释这些数据？
请帮我。
As per my understanding, Content Provider is a means for accessing database contents.
And to access the database, the Authority part is required. This authority part is provided by CONTENT_URI.
Thus Content_URI is a means for giving authority to the database.
As far as CONTENT_URI is concerened, it is generally of the form
content://com.example.transportationprovider/trains/122
______ |____________________________________|_____ |___
A B C D
Where A = Content,
B = Authority Part
c = Path determining what data to request
D = specific data
Above scenario is a ideal scenario where-in we pass /trains as the only database name.
But what if, i have the following content_uri:
content://com.example.transportationprovider/land/bus/133
In this case, /land/bus is the path segments.
But then internally how this data is stored in the database ?
Or how content Provider interpret this data?
Please help me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简单的答案是，它可以按照您喜欢的方式存储在数据库中。路径中的所有内容以及路径到下面数据库的映射都是由 ContentProvider 的编写者定义的。
或多或少，您想要使用的模型是数据库中的每个表都有一个路径。
在某些情况下，您可能需要一些额外的路径。通常，这意味着公开数据库的一些备用“视图”... Contacts API 提供了一个很棒的功能这方面的例子。
为什么要强制实施这种“陆地/公共汽车”雇佣制度？为什么不只是“公共汽车”和“火车”。每个都有一个 SQL 表？ SQL 表不是 Java 类。他们没有继承关系，这种雇佣关系也没有必要。
The simple answer is that it's stored in the database however you like. Everything in in the path, and the mapping of the path to the database underneath, is defined by the writer of the ContentProvider.
More or less, the model you want to use is that you have one path per table in your database.
There are some cases where you might want some additional paths. Typically, this means exposing some alternate "view" of the database... The Contacts API provides a great example of this.
Why do you want to enforce this kind of hirearchy "land/bus"? Why not just "bus" and "train". with one SQL table each? SQL tables are not Java classes. They don't have inheritance relationships and that sort of hirearchy isn't necessary.