following the doc to get propel up and running with symfony2 (http://www.propelorm.org/cookbook/symfony2/working-with-symfony2.html) leads to an fatal error:

PHP Fatal error:  Class 'Symfony\Bridge\Propel1\Logger\PropelLogger'

looking on the propel github account i have seen:

Important: The master branch follows the Symfony2 master branch, and uses the Propel Bridge. If you want to use the
bundle with a Symfony2 version 2.x.x (actually, a version which is not 2.1 or above), please use the 2.0 branch.

but i think its important, that the offical doc should lead in a working setup. docs should be fixed.

Hi,

Spent some time getting this bundle working as I much prefer Active Record over what Doctrine2 has become.

I've noticed an issue with the base peer classes, in that I get this error:

Fatal error: Class 'MyModule\MyBundle\Model\om\Propel' not found in /var/www/clients/client4/web12/symfony/src/MyModule/MyBundle/Model/om/BaseUserQuery.php on line 499

To get it running properly, I have to add these two statements to each base class:

use \Propel;
use \BasePeer;

So the top of the file now looks like this:

In Symfony2, all classes making relations between components has been moved to some "Bridge" components.
It's explained here: http://groups.google.com/group/symfony-devs/browse_thread/thread/ae49ea50a3731628/c5b268d63f195a19

The PropelBundle contain a lot of interesting things to work with Symfony Form Component.

In order to use Propel with the Form component outside of the framework, it would be useful to move the Propel\PropelBundle\Form classes out of the bundle. Something like Propel\Bridge\Form.

Hi

it would really be nice if we could write schemas in YML like in sfPropelORMPlugin again.

Regards
Tschebel

I just noticed that to run the propel:build-sql command we need to be in PHP 5.3.6.

I think it can be usefull to warn users of this or change the use of the "splFileInfo::getExtension" method in the BuildSqlCommand.

Since the fix of #62 the propel.platform.class property in the propel.ini is not observed anymore.

The method getConfiguredPlatform of the class GeneratorConfig now always sets the class name based on the connection adapter instead of observing the propel.platform.class property.

For this either the order of the checked conditions have to be changed in the getConfiguredPlatform method or this fix has to be reverted.

Probably this patch could be a solution?

### Eclipse Workspace Patch 1.0
#P amsCore
Index: plugins/sfPropelORMPlugin/lib/vendor/propel/generator/lib/config/GeneratorConfig.php
===================================================================
--- plugins/sfPropelORMPlugin/lib/vendor/propel/generator/lib/config/GeneratorConfig.php    (revision 4026)
+++ plugins/sfPropelORMPlugin/lib/vendor/propel/generator/lib/config/GeneratorConfig.php    (working copy)
@@ -154,14 +154,15 @@
    public function getConfiguredPlatform(PDO $con = null, $database = null)
    {
        $buildConnection = $this->getBuildConnection($database);
-       if (null !== $buildConnection['adapter']) {
-           $clazz = Phing::import('platform.' . ucfirst($buildConnection['adapter']) . 'Platform');
-       } elseif ($this->getBuildProperty('platformClass')) {
+       if ($this->getBuildProperty('platformClass')) {
            // propel.platform.class = platform.${propel.database}Platform by default
            $clazz = $this->getClassname('platformClass');
+       } elseif (null !== $buildConnection['adapter']) {
+           $clazz = Phing::import('platform.' . ucfirst($buildConnection['adapter']) . 'Platform');
        } else {
            return null;
        }
+       
        $platform = new $clazz();
 
        if (!$platform instanceof PropelPlatformInterface) {

I encountered a problem when running propel:build-model. Apparently Pdo_mysqlPlatform does not exist anymore:

propel > om-template:

[propel-om] Loading XML schema files...
[PHP Error] include_once(platform\Pdo_mysqlPlatform.php): failed to open stream: No such file or directory [line 1060 of C:\www\outotec.ofil_plant\vendor\phing\classes\phing\Phing.php]
Execution of target "om" failed for the following reason: C:\www\outotec.ofil_plant\vendor\propel\generator\build-propel.xml:525:22: Execution of the target buildfile failed. Aborting.
[phing] C:\www\outotec.ofil_plant\vendor\propel\generator\build-propel.xml:525:22: Execution of the target buildfile failed. Aborting.

I fixed this problem temporarily in a very ugly way.

Phing::__import() function, modiftied from

$ret = include_once($path);

to

if (preg_match('#Pdo_mysqlPlatform.php#i', $path)) {
    $ret = include_once('platform/mysqlPlatform.php');
} else {
    $ret = include_once($path);
}

and GeneratorConfig::getConfiguredPlatform() modified to have this line before new $clazz:

$clazz = str_replace('Pdo_', '', $clazz);

I am hoping to see official patches that fix the problem the real way.

Hi,

Today I faced this issue :

propel > sql-template:

[propel-sql] Loading XML schema files...
Execution of target "sql-template" failed for the following reason: .../vendor/propel/generator/build-propel.xml:203:10: Error setting up column 'model_number': Cannot map unknown Propel type 'STRING' to native database type.
[phingcall] .../vendor/propel/generator/build-propel.xml:203:10: Error setting up column 'model_number': Cannot map unknown Propel type 'STRING' to native database type.
Execution of target "sql" failed for the following reason: .../vendor/propel/generator/build-propel.xml:188:22: Execution of the target buildfile failed. Aborting.
    [phing] .../vendor/propel/generator/build-propel.xml:188:22: Execution of the target buildfile failed. Aborting.

BUILD FINISHED

Total time: 0.3230 seconds

  [Propel] You are running the command: propel:build-sql

  [ErrorException]                                                                                                                                                                                             
  Warning: rename(.../app/propel/sql/c4ea2e1bdb85984b0b1dd960001894e6_schema.sql,.../app/propel/sql/XXXWebsiteBundle-schema.sql): No such file or directory in .../vendor/symfony/src/Symfony/Component/HttpKernel/Util/Filesystem.php line 140

The text had a normal background except for the ErrorException which had a red background. In fact, the rename fails because the schema could not be generated due to some errors (in this case, I used "string" as a column type ... damn doctrine habit ;) ).

It would be great to raise a proper exception when the schema building fails.

Regards.

Also, the message displayed after inserting the SQL is wrong

php app\console propel:insert-sql --force

  [Propel] You are running the command: propel:insert-sql
Use connection named default in dev environment.

  <info>All SQL statements have been generated.</info>

In fact, it should say All SQL statements have been executed.

I'm not sure if the problem is in Propel or PropelBundle or somewhere else, please let me know if this is posted in the wrong place.

Afternoon!,

After much (more) struggling to get symfony2 to use Propel as a provider for security, I believe I've come across a further couple of issues, I'm listing them here should anyone wish to investigate.

1. Within : Propel\PropelBundle\Security\User\ModalUserProvider (line 93)
   This is given as 'if ($user instanceof $this->class) {', are you sure it shouldn't be 'if (!($user instanceof $this->class)) {' ?
   It continually throws a "There is no user provider for user" exception in it's initial state (via (sf) firewall ContextListener), but works as expected when negated.

2. Within : Propel\PropelBundle\Security\User\ModalUserProvider (line 64 & 65)

ucfirst($property) should be (I believe), ucfirst($this->property) (causes fatal error in current form)

Feel free to drop me an email or catch me in #propel (nick=drjones69) for any clarification.

Regards,
Ryan

I'm trying to override some propel's build class, like PHP5PeerBuilder, but in the php.ini file the base path for the propel.builder.peer.class seems to be unadapted for the project.

I have to set it in absolute mode because in relative there is no base path that allow me to include a class in my bundle.

Example:
My PeerBuilder class is in src/Namespace/MyBundle/propel/PeerBuilder.php, if i want to overide the PHP5PeerBuilder of Propel with this class i think the propel.builder.peer.class must be set with 'src.Namespace.MyBundle.propel.PeerBuilder'.

But in this way it doesn't working because the php include_path doesn't contain the root dir of the project.

i was following the guide linked at:
http://www.propelorm.org/cookbook/symfony2/symfony2-and-propel-in-real-life.html

when i arrive in the insert-sql step, there seems to be a problem:

the tables are NOT written in the database.
my database is called "test", and reading the sources, i found that it
NEVER reach the part of the sql file reading, because of a control a
step before:

in the PropelsqlManager , at the InsertSql method:
inside that, there is a foreach .
in my situation it quits the foreach before reading the sql file,
because the condition

if (null !== $datasource && $database !== $datasource) { 
  // skip 
  break; 
} 

results true: my database is 'test' , and the datasource is
'default' so it breaks the foreach and never reaches the sql query part.

the problem seems to be the same even in the controllers, but the connection works if from the configuration i create different data sources with something similar to this:

propel:
  connections:
    default:
      driver:     %database_driver%
      user:       %database_user%
      password:   %database_password%
      dsn:          %database_driver%:host=%database_host%;dbname=%database_name%;charset=%database_charset%
    test: # <- this is the database name
      driver:     %database_driver%
      user:       %database_user%
      password:   %database_password%
      dsn:        %database_driver%:host=%database_host%;dbname=%database_name%;charset=%database_charset%

If you use the insert-sql command, propel will execute all the insert-sql script, even if a --connection parameter is specified.

Hi,

Today we got a big issue with one of our sf2 command.

If a SF2 command call a Propel class/constant in the configure method of a command it will fail if the model is not already build (that's normal, class base missing)

But in that case I try to execute app/console propel:build-model and got the same error (and this is bad because I have to disable my bundle to execute the propel:build-model, I was lucky that my command was not in the same bundle has my Model.

I think there could be some way to fix that:

• made propel:build-model callable without SF2 loading all command (direct call)
• protect any console load to prevent it from failling (@fabpot did you think it's possible ?)
• add line to documentation saying: never call any propel class in command's configure

How to reproduce

Create a table called match.

Dump the data with app/console propel:fixtures:dump

It fails with the following error.

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'match' at line 1

This is caused because match is some reserved word by mysql.

Proposed fix:

--- a/DataFixtures/Dumper/AbstractDataDumper.php
+++ b/DataFixtures/Dumper/AbstractDataDumper.php
@@ -104,11 +104,11 @@ abstract class AbstractDataDumper extends AbstractDataHandler implements DataDum
             } else {
                 $in = array();
                 foreach ($tableMap->getColumns() as $column) {
-                    $in[] = strtolower($column->getName());
+                    $in[] = "`".strtolower($column->getName())."`";
                 }
                 $stmt = $this
                     ->con
-                    ->query(sprintf('SELECT %s FROM %s', implode(',', $in), constant(constant($tableName.'::PEER').'::TABLE_NAME')));
+                    ->query(sprintf('SELECT %s FROM `%s`', implode(', ', $in), constant(constant($tableName.'::PEER').'::TABLE_NAME')));
 
                 $resultsSets[] = $stmt->fetchAll(PDO::FETCH_ASSOC);
                 $stmt->closeCursor();

Please note, the second one fixes it. But I think it is a good idea to do the same for the column names ;-).

Should I forked it and fix it and adding a unit test for it?

Hi,

Yesterday's commit c04664b make the build SQL task crash in my project.

The --verbose option gives me the following error :
[PHP Error] file_put_contents(/var/www/dev/myproject/app/propel/sql/var/www/dev/project/src/X/ModelBundle/Model.schema.sql): failed to open stream: No such file or directory [line 166 of /var/www/dev/myproject/vendor/propel/generator/lib/task/PropelSQLTask.php]

The path where it tries to write the sql file is wrong.

Regards.

It could be nice to provide a ModelUserProvider for the Security component.

See: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/Security/User/EntityUserProvider.php

Hi there,

We fixed a potential SQL injection in the following commit: propelorm/Propel#27.

Unfortunately, this bundle forces the charset value, moreover it adds it in settings attributes which is bad for PHP versions under 5.3.6.

The bundle should be refactored to:

• delete the charset parameter from the service container ;
• delete the charset option (which is global and it does not make sense) ;
• do not force the charset value ;
• add the charset in the dsn value ;
• detect whether there is a configured charset or not ;

This should be easy as it's mainly focused on the configuration part.

Regards,
William.

Records with foreign keys need to be exported after their related data is loaded. The logic in the fixOrderingOfForeignKeyData method of AbstractDataDumper.php has a bug.

        foreach ($tableMap->getColumns() as $column) {
            if ($column->isForeignKey()) {
                $relatedTable = $this->dbMap->getTable($column->getRelatedTableName());
                $relatedTablePos = array_search($relatedTable->getPhpName(), $classes);

getPhpName returns a string like 'Event', but $classes contains an array of the full class name, e.g. Acme\StoreBundle\Model\Event, so it will never reorder.

I think the call should be to something like $relatedTable->getClassName() or getModelClassName() or something that returns the full namespace, but I'm not sure what that is.

How the XML fixtures loading works is not viable.

The XML model used to represent objects is not really usable. Moreover the datasql task is a pain if we work with multiple connections.
What we have to do is to create a fixtures loader "à la symfony 1.4" :)

$artists = SonglistQuery::create()
            ->select(SonglistPeer::ARTIST)
            ->setDistinct(SonglistPeer::ARTIST)
            ->find();

This results in the following SQL which fails with a syntax error...

SELECT DISTINCT AS "songlist.ARTIST" FROM `songlist`

The AS should not be there.

After an update of the bundle (due to using sf vendor management) - it updates existing packages when installing new ones.
I get a fatal error:

Fatal error: Class 'Symfony\Bridge\Propel1\Logger\PropelLogger' not found in ~/app/cache/dev/appDevDebugProjectContainer.php on line 1059

This is because there is no Symfony Propel1 Bridge - this is only available when using the latest version of symfony (master branch)

Is there a known work around or do you have any suggestions how I might fix this ?

Just doing a git pull in Symfony breaks the required Doctrine link - so this is a no-no.

This is tested with both the standard with and without vendors sf 2.0.6 packages.

Based on this: https://github.com/propelorm/sfPropelORMPlugin/blob/master/lib/addon/sfPropelData.class.php#L329 and according to the recent changes on how fixtures work, we have to create a new data dumper command like the fixtures command work.

We should be able to choose the output format (YAML, XML) and the transformation process will be handled by a specialized class. That means we will have to write :

• an AbstractDataDumper class which will handle the most part of the work
• an XmlDataDumper class which will know how to transform an array into XML
• a YamlDataDumper class which will know how to transform an array into YAML

The namespace will be: Propel\PropelBundle\DataFixtures\Dumper. We will also move the loader layer to : Propel\PropelBundle\DataFixtures\Loader.

The main validation will be to load fixtures/dump fixtures without any problems.

In symfony 1, the web debug toolbar used quick'n dirty syntax highlighting to make the SQL Queries panel more readable. Why not use the same technique in PropelBundle?

The SQL syntax highlighter from symfony 1 is simple enough to be defined as a Twig filter using an anonymous function:

// taken from sfWebDebugPanel.class.php
function formatSql($sql)
  {
    return preg_replace('/\b(UPDATE|SET|SELECT|FROM|AS|LIMIT|ASC|COUNT|DESC|WHERE|LEFT JOIN|INNER JOIN|RIGHT JOIN|ORDER BY|GROUP BY|IN|LIKE|DISTINCT|DELETE|INSERT|INTO|VALUES)\b/', '<span class="SQLKeyword">\\1</span>', $sql);
  }

Then, in the Resources/views/Collector/propel.html.twig template, simply add the filter to the query log:

{% block panel %}
    {# the panel content #}

    <h2>Queries</h2>
    <table summary="Show logged queries">
        <thead>
            <tr>
                <th>SQL queries</th>
            </tr>
        </thead>
        <tbody>
        {% if not collector.querycount %}
            <tr><td>No queries.</td></tr>
        {% else %}
            {% for query in collector.queries %}
            <tr>
                <td>
                    <code>{{ query.sql|formatSQL }}</code>
                    <div style="color: gray;font-size: 0.9em;">Time: {{ query.time }} - Memory: {{ query.memory }}</div>
                </td>
            </tr>
            {% endfor %}
        {% endif %}
        </tbody>
    </table>

    {% render 'PropelBundle:Panel:configuration' with { 'collector': collector } %}
{% endblock %}

A bit of CSS to put SQL keywords in another color, and you're good to go.

Related to : propelorm/Propel#80

Some commands are using other commands but in a wrong way. We should refactor that part.

The existing code is more or less as below:

<?php

$cmd = new FooCommand();
$cmd->execute();

This is wrong and I don't know how it can work.. The execute() method is protected.

The right way is:

<?php

$in = new ArrayInput(array(
       'command'        => 'foo',
       '--verbose'      => $input->getOption('verbose'),
));

$cmd = $this->getApplication()->find('foo');
$cmd->run($in, $output);

Using the table attribute baseClass in my schema.xml does nothing to my baseObject.

My schema.xml looks like this, maybe I made a mistake:

<?xml version="1.0" encoding="UTF-8"?>
<database defaultIdMethod="native" namespace="BundleNamespace\Model" name="default">
  <table name="film" baseClass="BaseObject">
    <behavior name="timestampable" />
    <column name="id" type="INTEGER" primaryKey="true" autoIncrement="true" required="true"/>
    <column name="title" type="VARCHAR" size="255" />
  </table>
</database>

And so my Object doesn't extends from my baseObject class.
It's even worse with a namespaced baseObject class as I can get far because the "" of the namespace makes an error:

[PHP Error] DOMDocument::schemaValidate(): Element 'table', attribute 'baseClass': [facet 'pattern'] 
The value '\Namespace\MyBundle\Model\BaseObject' is not accepted by the pattern '([\w_]+.?)+'. 
[line 442 of /home/mailloud/workspace/referentiels/vendor/propel/generator/lib/task/AbstractPropelDataModelTask.php]

So to deal with that I overload the PHP5ObjectBuilder and changed the extended class.

As I'm not following Symfony master I use the 2.0 branch of the PropelBundle.

Current classes output directory (src/Acme/MyBundle/Model) makes the model impossible to reuse.

If you want to set a relation to a table stored under a different bundle, you have to overwrite model classes within the bundle, making it exclusive to the current app.

So I suggest setting the output to %kernel.root_dir%/propel/%appName%PropelModel /Full/Source/Bundle/Namespace /schema/defined/package.

For example if we have

<database name="default" defaultIdMethod="native" package="foo">
...

in src/Acme/MyBundle/Resources/config/schema.xml

the generated model goes to myapp/propel/MyappPropelModel/Acme/MyBundle/Foo under MyappPropelModel\Acme\MyBundle\Foo namespace and propel.generator.MyappPropelModel.Acme.MyBundle.Foo package

Besides that solves the "dots in path" problem.

Alternatively it would be nice to have PhingCommand registered as a service and divide callPhing into several functions, making generation output overridable via config, cause with current architecture I had to patch PhingCommand manually.

When I run the command php app/console propel:fixtures:dump

I get the following error:

[Propel] Exception
SQLSTATE[42S02]: Base table or view not found: 1146 Table '[dbname].book' doesn't exist

This is probably because the Bundle has Tests written which result in a BookTableMap.php

Possible solution:
in /DataFixtures/AbstractDataHandler.php replace line 67
$files = $finder->files()->name('*TableMap.php')->in($this->getRootDir() . '/../');

with
$files = $finder->files()->name('*TableMap.php')->in($this->getRootDir() . '/../')->exclude('Tests');

this way it will exclude Tests TableMaps

Today, the bundle comes with a lot of features and it's time to stop the lack of unit tests.
Even if the most important part of this bundle is ever unit tested, commands are not.

This issue will be open until the whole bundle will be tested :)

To respect the Symfony2 convention, we have to change the base namespace from Propel to Propel\Bundle.
As it's not BC, we'll make this change when Symfony 2.1 will be available (more or less).

William

/ping @hhamon

@nibsirahsieu reported the following bug:

Its seem the build properties that are defined in the propel.ini was ignored when building sql file. it'll work if the build properties is defined in the app/config/config.yml.

The error message is not applied to the field but on the form because the field name and the property are different.

You should change the namespace of the bundle. Adding a submodule inside the Symfony submodule don't work so it would be easier if this bundle does not use Symfony\Bundle as its namespace.

Anyway this is only a suggestion to help Propel users but I personnaly don't care as I'm not one.

This is the app/config/config_dev.yml:

propel:
dbal:
driver: pgsql
user: skyisblue
password: skyisblue
dsn: pgsql:host=localhost dbname=symfony2

"php app/console propel:database:create" needs pgsql database in order to be able to create symfony2 database.

Shouldn't creating database need not another database?

When you load the fixtures.yml in an other bundle then the bundle where the model is defined. The releations can't be found.

This is caused becasue the lookup array ($this->object_references) is using class names. Where there is looked for PHP names.

Possilbe fix

diff --git a/DataFixtures/Loader/AbstractDataLoader.php b/DataFixtures/Loader/AbstractDataLoader.php

index 36a57b8..9cd0ba4 100644

--- a/DataFixtures/Loader/AbstractDataLoader.php

+++ b/DataFixtures/Loader/AbstractDataLoader.php

@@ -189,13 +189,13 @@ abstract class AbstractDataLoader extends AbstractDataHandler implements DataLoa

if ($isARealColumn) {

if ($column->isForeignKey() && null !== $value) {

$relatedTable = $this->dbMap->getTable($column->getRelatedTableName());


                       if (!isset($this->object_references[$relatedTable->getPhpName().'_'.$value])) {



                       if (!isset($this->object_references[$relatedTable->getClassname().'_'.$value])) {
                         throw new \InvalidArgumentException(



                               sprintf('The object "%s" from class "%s" is not defined in your data file.', $value, $relatedTable->getPhpName(



                               sprintf('The object "%s" from class "%s" is not defined in your data file.', $value, $relatedTable->getClassnam
                         );
                     }
                     $value = $this



                           ->object_references[$relatedTable->getPhpName().'_'.$value]



                           ->object_references[$relatedTable->getClassname().'_'.$value]
                         ->getByName($column->getRelatedName(), BasePeer::TYPE_COLNAME);
                 }
             }

In order to be consistent with the Propel Bridge

When you configure your cache directory to an other location than the default one in Symfony this setting is not used by propel.

Please consider this fix:

Index: Symfony/vendor/bundles/Propel/PropelBundle/Command/AbstractPropelCommand.php
===================================================================
--- Symfony/vendor/bundles/Propel/PropelBundle/Command/AbstractPropelCommand.php    
+++ Symfony/vendor/bundles/Propel/PropelBundle/Command/AbstractPropelCommand.php    
@@ -96,7 +96,7 @@
         if (isset($properties['propel.schema.dir'])) {
             $this->cacheDir = $properties['propel.schema.dir'];
         } else {
-            $this->cacheDir = $kernel->getRootDir().'/cache/' . $kernel->getEnvironment() . '/propel';
+            $this->cacheDir = $kernel->getCacheDir(). '/propel';

             $filesystem = new Filesystem();
             $filesystem->remove($this->cacheDir);

Symfony2 RC1 changes how commands work, so now by default, there will be an error:
PHP Fatal error: Class 'Symfony\Bundle\FrameworkBundle\Command\Command' not found

Will see what else needs to be changed to work with RC1..

You need to add this line to make the default connection works

$c['datasources']['default'] = $connectionName;

line 109 PropelExtension.php

I ran into an issue using the FOSUserBundle: FriendsOfSymfony/FOSUserBundle#560 (comment)

The guys there said it has to do with the way the propelbundle generates it's classes.

To recap:
Many people deploy using git these days. Because the model classes are generated inside the bundles inside 'vendor' they cannot be committed (read only submodules). Thus there is no way to deploy using git as is required by services like Cloudcontrol, phpFog etc.

I ended up just downloading a zip and copying the files in 'vendor/' so I could commit in my repo.

Is this desired behavior?

There's a file called AbstractPropelCommand, its path is vendor/bundles/Propel/PropelBundle/Command/AbstractPropelCommand.php

On line 510 there's some configuration being set, the function is getPhingArguments... it's an array being set with the key propel.database to "mysql". In order to reverse engineer a PgSQL database I had to set it to pgsql, but I think in future releases it should be a parameter.

I hope this helps anyone :)

I think the documentation is not up-to-date but there is an error in it for setting the charset value.

It's written:

settings:
charset: { value: UTF8 }

But in fact to make it work it has to be:

settings:
charset: UTF8

I think that it would be usefull to have integration with symfony's security and some default values for logging.
When using log_created_at, log_created_by and log_comment, if no value are passed via the methods, it could be possible to put some default:

• date time modification in log_created_at
• short description (created, updated, deleted) in log_comment
• the user informations

To do that, the programmer should be able to provide some more info, in the schema.xml, like:

<parameter name="use_default_for_log_created_at" value="true" />
<parameter name="use_default_for_log_comment" value="true" />
<parameter name="use_default_for_log_created_by" value="true" />
<parameter name="symfony_security_user_method" value="true" />

To do that, I think it would be necessary to override, in the bundel, propel versionable behaviour generators. So my questions are:

• do you think this could be usefull ?
• do you think this could be feasible ?
  If both answer are yes, I'll start working on it!

When adding the PropelBundle in the deps file in order to update it when updating Symfony and other libraries i get this error:

fatal: ambiguous argument 'origin/HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

I added this lines to my deps file:

[PropelBundle]
git=git://github.com/propelorm/PropelBundle
target=/bundles/Propel/PropelBundle

I got the same error with Propel.

After a lot of fiddling I managed to get the vendors to update properly in the Symfony 2.0.6 without vendors workspace.

For the record, I used the following deps and deps.lock settings, and followed https://github.com/propelorm/PropelBundle/blob/master/Resources/doc/README.markdown.

deps

[propelbundle]
    git=https://github.com/propelorm/PropelBundle.git
    target=/bundles/Propel/PropelBundle

[propel]
    git=https://github.com/propelorm/Propel.git
    #git=https://github.com/propelorm/Propel2.git

[phing]
    git=https://github.com/Xosofox/phing.git

deps.lock

propelbundle a7ed277e78513749bcbf3c0baab2f9f3fe8dd9ab
propel aac86e0e45b10228032e97b662388185ce071c70
phing 1fd92c78f14a02b3e1cd9c59c7a08b4cab532d33

It seems to me that there is no way to set the build.properties settings. Also I have never seen any example of what values to put into the options{} and attributes{} configuration keys.

When I generate my SQL using app/console propel:build the result is a .sql file stating "ENGINE=MyISAM". After scanning the sourcecode and documentation I found no clue how to actually set build.properties. In an helpless attempt I inserted "propel.mysql.tableType = InnoDB" into the empty app/propel/schema/build.properties file. It did not get overridden but neither did it result in any changes to the generated SQL.