问题标签 [petapoco]

I have a class User withthe definitions: ID, Name, CustomerID and a class Customer with the definitions: ID, Name, Address

I am trying the following query but I`m having the error message, Incorrect syntax near the keyword 'user'.

What is wrong with the sql?

I am trying to write the sql

我正在尝试使用表达式树和匿名类型来实现以下目标。

假设我有这个课程：

现在我希望能够调用以下内容：

我希望名称包含 2 个项目，“LastName”和“DateOfBirth”。

我正在尝试以编译时安全的方式扩展PetaPoco，而不是编写字符串 sql，以便我可以指定要包含在 SQL 中的属性/列的列表，而不是选择所有内容。我有一些相当大的实体，在某些情况下，出于性能原因我不想选择所有列。

我有一个在 AppHarbor 上运行的 Asp.net MVC 应用程序。它有日常的电子邮件订购流程：

1. 用户输入他们的电子邮件并提交。
2. 系统处理订单并发送带有链接的电子邮件。
3. 用户检查电子邮件并单击链接以执行下一步...

问题是在步骤#2 和#3 之间有很多时间可以过去。有些用户会立即检查他们的电子邮件，有些用户会在一天甚至更晚之后查看。主要是足够的时间可以通过服务器上的应用程序结束。

因此，当用户单击链接时，这可能意味着他们必须等待一段时间才能启动应用程序...

问题

datetime当步骤 #3 处理数据库中的记录时，会在步骤 #3 发生时使用时间戳（类型当然是）更新。但请理解：我可以看到时间戳完全相同的记录！这怎么可能发生？

时间戳在应用层生成，然后将更新的内容推送到数据库。我正在使用 PetaPoco 进行数据访问。

什么会导致多条记录同时记录？我的应用程序的流量如此之小，以至于它实际上有时会在白天关闭，所以我很难相信多个（最多三个）用户同时执行了第 3 步。而且由于这是在单个进程上运行的，我想这是不可能的......

这可能是什么原因？

更新代码真的很简单

如果我有一个ResultColumn设置了属性的 POCO 类，然后当我进行Single<Entity>()调用时，我的结果列不会被映射。我已将我的列设置为结果列，因为它的值应始终由 SQL 列的默认约束生成。我不希望从业务层注入或更新此列。我想说的是，我的列的类型是简单的 SQL 数据类型，而不是相关的实体类型（正如我所看到ResultColumn的那样，主要用于这些类型）。

查看代码我可以在 PetaPoco 中看到这一行：

为什么从自动选择语句中排除结果列，因为据我了解，它们的性质是只读的。所以只用于选择。当列实际上是相关实体类型（复杂）时，我可以看到这种情况。行。但是我们应该有一个单独的属性ComputedColumnAttribute，这样总是在选择中返回，但从不在插入或更新中使用......

为什么 PetaPoco 团队决定从选择中省略结果列呢？
那我应该如何阅读结果列？

我正在尝试使用 ODBC 连接到 Navision 2.60。我有一个静态类来管理 odbc 连接。

我想使用 ORM 来映射 Petapoco 或 Dapper 等实体，有人有这样做的例子吗？

我正在开发一个基于网络的便士拍卖门户。我使用 PetaPoco 作为我的具有 Asp.net MVC 3 架构的数据访问类库。我正面临使用存储过程提取多表数据的问题。我创建了一个视图模型 POCO 用于映射存储过程字段，我需要在前端。

查看型号：

控制器

我需要的

我需要从具有多个连接的数据库中提取数据并使用存储过程（使用我的视图模型类）显示在视图上。

我有一个查询

这是给出错误消息：

无法绑定多部分标识符“Condition.ID”。FROM 子句中的对象“Issue”和“Issue”具有相同的公开名称。使用相关名称来区分它们。

上面穿的是什么？

有什么方法可以使用 petapoco 和 mvc3 进行有效的分页。目前我正在提取所有记录，这当然不是一个完美的方法。

使用 LINQ skip() take() 非常容易。

注意：这将在拍卖门户中实施，并且数据库将非常庞大。

请高手指点一下。

我开始使用 PetaPOCO 和 Dapper，它们都有自己的局限性。但相反，它们比实体框架快如闪电，我倾向于放开它的限制。

我的问题是：是否有任何 ORM 可以让我们具体定义一对多、多对一和多对多关系？Dapper.Net 和 PetaPOCO 都采用黑客式的方式来伪造这些关系，而且当您可能有 5-6 个连接时，它们甚至不能很好地扩展。如果没有一个微型 ORM 可以让我们处理它，那么我的第二个问题是我是否应该放弃这些微型 ORM 在定义关系方面不是很好的事实，并为每种类型创建一个新的 POCO 实体我将执行的包含这些类型的多连接的查询？这可以很好地扩展吗？

我希望我的问题很清楚。如果没有，请告诉我。

我们当前的应用程序使用智能对象样式来处理数据库。我们正在研究改用 PetaPoco 的可行性。查看我注意到的功能，您可以添加属性以使 CRUD 对象更容易。添加这些属性是否有任何我应该注意的负面影响？

有没有人找到不使用这些装饰器的理由？