matatirosoln/doctrine-fm-data-api-driver 问题修复 & 功能扩展

解决BUG、新增功能、兼容多环境部署,快速响应你的开发需求

邮箱:yvsm@zunyunkeji.com | QQ:316430983 | 微信:yvsm316

matatirosoln/doctrine-fm-data-api-driver

Composer 安装命令:

composer require matatirosoln/doctrine-fm-data-api-driver

包简介

Use FileMaker via the v17+ Data API as your backend database

README 文档

README

A Doctrine driver to interact with FileMaker using the v17+ Data API v1.

Installation

composer require matatirosoln/doctrine-fm-data-api-driver

Note: We recently update the version of Guzzle used by this library to v7 which requires PHP >= 7.2. If you are still working with an earlier version of PHP then require version ^0.7.5 of this library.

Configuration

In your Doctrine configuration comment out

driver: xxxx

and replace it with

driver_class: MSDev\DoctrineFMDataAPIDriver\FMDriver

Conventions

  1. Create a model to represent a FileMaker layout. Set the name of the layout as the model table.

     /**
      * Keyword
      *
      * @Table(name="Keyword")
      * @Entity(repositoryClass="Repository\KeywordRepository")
      */
      class Keyword
    
  2. In your model create an id field which is mapped to the special rec_id pseudo field

     /**
      * @var int
      *
      * @Column(name="rec_id", type="integer")
      */
     private $id;
    
  3. Create your 'actual' ID field, as used for relationships, as a separate property of your model. Set its GeneratedValue strategy to be Custom which will mean that Doctrie will wait for FM to assign that value - the assumption being that this is an auto-enter calc field (probaby Get(UUID)). You then need to specifiy the CustomIdGenerator and set this to MSDev\DoctrineFMDataAPIDriver\FMIdentityGenerator so that the value is returned as a string.

    /**
     * @var string
     *
     * @Column(name="__pk_ClientID", type="string" length=255)
     * @Id
     * @GeneratedValue(strategy="CUSTOM")
     * @CustomIdGenerator(class="MSDev\DoctrineFMDataAPIDriver\FMIdentityGenerator")
     */
    private $uuid;
    

    Alternatively you could generate the UUIDs in your model constructor (using for example ramsey/uuid). In this case you'd end up with something like

     /**
      * @var string
      *
      * @Column(name="__pk_CanvasID", type="string", length=255)
      * @Id
      */
      private $uuid;
      
      public function __construct()
      {
          $this->uuid = Uuid::uuid4()->toString();
      }
    
  4. Add other properties as required. To access related fields on your layout enclose the field name in single quotes in the column mapping.

      /**
       * @var string
       *
       * @Column(name="'absCon::email'", type="string", length=255)
       */
      private $contactEmail;
    
  5. If you need access to the record modification ID you can add the special mod_id pseudo property

     /**
      * @var int
      *
      * @Column(name="mod_id", type="integer")
      */
     private $modId;
    

Considerations

  1. Because of the way in which more 'conventional' databases handle relationships, there is no concept of a portal. To access related data create a corresponding model for that table (layout) and create standard Doctrine relationships (OneToOne, OneToMany, ManyToOne etc).
  2. If your model contains calculation fields you will run into issues when trying to create a new record, since Doctrine will try and set those fields to null. One 'solution' to this is to create a 'stub' of your model which contains only the fields which are necessary to create a new record and to instantiate that for record creation. If you head down this route you'll likely want to create an interface which both your stub and your real entity implement so that you can typehint appropriately.
  3. If you wish to perform an IN query, then it needs to be the last andWhere set in the query builder so that the previous conditions will be applied to all of the query objects which the Data API requires to simulate an IN query.

See also

This driver has been developed for use within Symfony applications (because that's what we do). The Doctrine FileMaker bundle creates services to access scripts, containers, etc.

matatirosoln/doctrine-fm-data-api-driver 适用场景与选型建议

matatirosoln/doctrine-fm-data-api-driver 是一款 基于 PHP 开发的 Composer 扩展包,目前已累计 1.3k 次下载、GitHub Stars 达 3, 最近一次更新时间为 2018 年 07 月 06 日, 在 PHP 生态内属于活跃度较高的组件。

它主要适用于以下技术方向: 「dbal」 「doctrine」 「FileMaker」 等业务场景。在实际项目中,围绕这些方向常见需要落地的问题包括:接口对接、性能调优、并发安全、与既有框架(Laravel / ThinkPHP / Yii / Webman 等)的兼容适配,以及生产环境的日志埋点与稳定性保障。

我们在过去多个企业项目中使用过 matatirosoln/doctrine-fm-data-api-driver 或与其功能相近的方案,如果你在选型或落地过程中遇到问题,例如 版本兼容、二次改造、私有化封装、与内部系统对接、生产 BUG 排查,欢迎联系我们协助评估。

围绕 matatirosoln/doctrine-fm-data-api-driver 我们能提供哪些服务?
定制开发 / 二次开发

基于 matatirosoln/doctrine-fm-data-api-driver 在你已有业务上做功能扩展、字段裁剪、UI 适配、与内部账号 / 权限 / 日志系统的深度对接。

BUG 修复 & 性能优化

线上偶发问题、内存泄漏、慢查询、并发异常等排查修复;针对高流量场景做缓存、队列、索引层面的调优。

项目外包 & 长期维护

承接完整的项目从需求 → 设计 → 开发 → 上线 → 长期运维;也可按月提供技术保姆服务。

yvsm@zunyunkeji.com QQ:316430983 微信:yvsm316 西安尊云信息科技 · 专注 PHP / Go / 分布式系统研发

统计信息

  • 总下载量: 1.3k
  • 月度下载量: 0
  • 日度下载量: 0
  • 收藏数: 3
  • 点击次数: 17
  • 依赖项目数: 0
  • 推荐数: 1

GitHub 信息

  • Stars: 3
  • Watchers: 1
  • Forks: 1
  • 开发语言: PHP

其他信息

  • 授权协议: MIT
  • 更新时间: 2018-07-06