Re: [Modeling-users] Core v0.8.2 released

[Mario R. <ma...@ru...>]

Thanks for the changes...

But, build (and install) fails:

% python setup.py build
...
copying=20
Modeling/DatabaseAdaptors/MySQLAdaptorLayer/MySQLSQLExpression.py ->=20
build/lib/Modeling/DatabaseAdaptors/MySQLAdaptorLayer
running build_scripts
creating build/scripts-2.2
error: file 'Modeling/scripts/generate_DB_schema.py' does not exist

Cheers, mario



On samedi, f=E9v 1, 2003, at 20:01 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:

>
>         Hi all,
>
>   The core v0.8.2 has just been released today.
>
>   Main changes are:
>
>     - full support for postgresql 7.3
>
>     - addition of the script 'generate_DB_schema.py' to (re)initialize=20=

> a
>       database from an xml-model ; this functionality was previously
>       only available within the ZModeler, now this can be done on the
>       command-line.
>
>   Other changes are bug-fixes as described in the changelog, included=20=

> at
>   the end of the message. Some of these adress bugs recently reported
>   here, such as the test_EditingContext_Global failing (w/ postgresql
>   7.3) when triggered more than once with '-r' option.
>
>   Last, two environment variables are added:
>
>     - POSTGRESQL_SERVER_VERSION (possible values: '7.2' or '7.3') =
--see
>       below for details
>
>     - ENABLE_DATABASE_LOGGING: set to an non-empty strings, enables
>       logging at DatabaseAdaptors level.
>
>         Best regards,
>
> -- S=E9bastien.
>
>
>   ---------------
>   0.8.2 CHANGELOG
>   ---------------
>
>   * Added scripts/generate_DB_schema.py (-h for help)
>
>   * Generation of SQL statements:
>
>     (Modeling, Modeling.interfaces, PostgresqlAdaptorLayer)
>     SchemaGeneration: the three following methods were added in the=20
> API:
>
>       - dropForeignKeyConstraintStatementsForRelationship
>       - dropPrimaryKeyConstraintStatementsForEntityGroup(s)
>
>     along with their associated constants DropForeignKeyConstraintsKey
>     andDropPrimaryKeyConstraintsKey.
>
>     The SchemaGeneration.defaultOrderingsForSchemaCreation() has also
>     been corrected (was wrong: alternation of drop+create statements
>     instead of having drop statements come in first, then create
>     statements in reverse-order)
>
>
>   + PostgresqlAdaptorLayer: now correctly generates create/drop SQL
>       statements for postgresql versions 7.2 and 7.3. Environment
>       variable 'POSTGRESQL_SERVER_VERSION' allows you to specify with
>       which version of the pg-server you're working with (default: =
7.2)
>       [Added for that purpose: PostgresqlAdaptorLayer.pg_utils]
>
>       Note: this corrects a bug in test_EditingContext_Global.py =
which,
>             when triggered with the '-r' option (recreate database),=20=

> was
>             not able to actually recreate the database for pg-server
>             v7.3. Thank you Mario <ma...@ru...> for the bug
>             report!
>
>   * Postgresql & psycopg:
>     PostgresqlAdaptorContext/adaptorChannelDidClose() now rollbacks =
the
>     underlying connnection object when using psycopg --if not done,=20
> this
>     leads to strange behaviour because changes committed by others are
>     never seen.
>
>   * SQLExpression: changes in the set of supported SQL datatypes
>
>     - SQLExpression.valueTypeForExternalTypeMapping(): Removed =
datetime
>       & timestampz from the list, added date & time
>
>     - Added MySQL/PostgresqlSQLExpression to the corresponding =
Database
>       Adaptors Layer:
>
>         Postgresql: additional supported datatypes are: 'datetime'
>                     (warning: not supported anymore for postgresql
>                     version>=3D7.3), 'timestamp without time zone' and
>                     'timestamp with time zone',
>
>         MySQL: additional supported datatype: 'datetime', removed
>         datatype: 'timestamp' (see
>         DatabaseAdaptors.MySQLAdaptorLayer.MySQLSQLExpression for a
>         complete explanation)
>
>     NB: ModelValidation has been updated to notify the problem with
>         postgresql and 'datetime'
>
>   * Database Adaptors logging:
>
>      - they do not log anymore the password they use when connecting =
to
>        a database (replaced by 'xxxx' so that a bug-report containing
>        log msgs or tracebacks will not disclose the password by=20
> mistake)
>
>      - it is not activated by default, except for error and fatal
>        msgs. To activate them, set the environment variable
>        ENABLE_DATABASE_LOGGING to any non-empty string.
>
>   * Fixed Qualifier.QualifierOperatorLike and
>     QualifierOperatorCaseInsensitiveLike: they were failing when
>     comparing the pattern to a value which is not a string, such as an
>     integer or a mxDateTime.
>
>   * ObjectStore: Added ownsObject(), and made handlesObject() an alias
>                  for ownsObject().
>
>   * tests.test_EC_Global.test_999_customSQLQuery() fixed: it failed w/
>     the pypgsql adaptor --see comments in code for details.
>
>   * PostgreqlAdaptorLayer & MySQLAdaptorLayer: Fixed: useless import
>     statements in __init__ were shadowing modules PostgresqlAdaptor =
and
>     MySQLAdaptor
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld  Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users