collective.behavior.sql 0.9.13

collective.behavior.sql

collective.behavior.sql
=======================

Overview
--------

collective.behavior.sql is a module intended to synchronize one or many sql databases with plone content using dexterity as content and sql table descriptor.

This module depends on sqlalchemy and z3c.saconnect to define the sql connections.


SQL Content Behavior
--------------------

After installing, a new behavior name "SQL Content" is available.
This behavior will allow you to choose the connection, source table and unique ID identifier (Primary Key) for your Dexterity SQL content.
After adding the SQL Content behavior, you will be able to specify wich column of the sql table corresponds to each field (existing or new) of your content type.

You can see all the data found in your SQL DB under the "Data" tab.
You can also specify a folder to act as container for the SQL items or add the SQL Dexterity content directly in plone like any other portal type and specify to which Primary Key your content corresponds. The module will the take data from the SQL DB for the specified fields.


Main features
----------

- All the configuration is done TTW, no need to code sql queries
- SQL datas can be added to the catalog like other standard content and therefore shown in search results, navigation, collections...
- SQL Behavior can handle relations between Dexterity SQL objects (RelationChoice, RelationList with one2many and many2many tables)
- SQL Dexterity items can be listed in a folder or added to the site like any other content
- Corresponding SQL column can be specified for both new fields and fields coming from other behaviors, so you can use SQL data for title, description, keywords, dates like effective, start end, ...


Limitations
-----------

At that time collective.behavior.sql cannot handle translations and workflow.
For the sql dexterity objects that are not added in the site (called virtual items) you will have to use a single state workflow set to "published".


Funding
-------

- `Idiap Research Institute <http://www.idiap.ch>`_, Martigny, Switzerland
- `Martronic SA <http://www.martronic.ch>`_, Monthey, Switzerland

- v 0.9.13 Fix getPhysicalPath for sql DX items with container stored as UID and not path

- v 0.9.12 Use UID instead of intid for storing SQL Items Folder
as this might break relations if portal is renamed
Fix virtual folder look for sql_virtual items only

- v 0.9.11 fix instance renaming by catching specific catalog mothods

- v 0.9.10 fix support of effective date and expiration date (field declared as "effective" but it looks for "effective_date"

- v 0.9.9 bug fix in dx sql type

- v 0.9.8 /@@data first search in catalog before creating objects on the fly

- v 0.9.7 added expire_on_commit=False to session maker to avoid SQLAlchemy DetachedInstanceError

- v 0.9.6 Catch sql connection errors on init so that the site doesn't break

- v 0.9.5 Register traverser with wrapped fti
Fix wrong variable when saving sql folder attribute of dx type.

- v 0.9.4 Use custom sqlachemy table naming to be able to get more than one foreign key table between two same tables

- v 0.9.3 Fix

- v 0.9.2 Use an unique name for relations as there can be multiple foreign keys linking the same two tables.
Fix to be sure all sql_id are strings and not integers

- v 0.9.1 Fixed The SQLContent publisher to get Folder container from RelationValue. Get it from
standard path might throw security issues.

- v 0.9 Use name instead of url to store sql_connection, so it's possible to change the url
in saconnect without losing its reference in type definition.

- v 0.8 Allow SQL DX item to be added in site (ZODB) and get par of its content from SQL.
Fix sqlalchemy session handling, several bug fixes

- v 0.7 Allow the use of relational table to get simple data as tuple (like keywords)

- v 0.4 Allow selection of all kind of columns for ID if SQL table type is a view

- v 0.3 Make possible the use of relations (Foreign Keys) many to one and many to many