Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [propel-dev] New Transaction setup

propel
Discussion topic

Hide all messages in topic

All messages in topic

Re: [propel-dev] datadump across multiple schema files

Reply

Author Robert Bruce <rob at tdd dot org dot uk>
Full name Robert Bruce <rob at tdd dot org dot uk>
Date 2006-10-02 05:37:41 PDT
Message Well I have thought about that, but the files are not being processed in
alphabetical order either, so I am not sure if that would be of any
benefit. I guess what would be beneficial is to work out the order in
which is processes the files, then control that so that they are in
correct order and see if the datadump succeeds.

On Mon, October 2, 2006 11:25 am, Luciano Andrade wrote:
> Ovbiusly you could try to renameit to some ting like
> 01Website.schema.xml 02Licencing.schema.xml
>
> But I realy don´t understend how the multi-schema definition works
> when you reference tables/relations from others schemas.
>
> On 10/1/06, Robert Bruce <rob at tdd dot org dot uk> wrote:
>> I have a system whereby I use a multi-component setup with propel, using
>> multiple schema files. Everything works fine for code generation and
>> installing the sql, however when I come to run a datadump an error
>> occurs regarding a missing table. The table does exist in the database,
>> but I believe the error is due to the schema files not been processed in
>> dependency order.
>>
>> Here is an output from attempting to run the datadump target
>>
>> http://www.tdd.org.u​k:81/propel.txt
>>
>> If you look at the order the schema files are processed the first file
>> licencing.schema.xml depends on the schema website.schema.xml which is
>> being processed further down the list. Is there any way can control the
>> order in which the schema files are processed? Or is there any other way
>> to get around this problem?
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] datadump across multiple schema files

Reply

Author Robert Bruce <rob at tdd dot org dot uk>
Full name Robert Bruce <rob at tdd dot org dot uk>
Date 2006-10-02 05:27:58 PDT
Message Yes I know it is, there are foreign keys across the schema files. However
the first schema file licensing.schema.xml is being processed prior to its
dependency, website.schema.xml.

Propel copes perfectly fine with foreign keys across multiple schema files
during the codegen process.

On Mon, October 2, 2006 12:20 pm, Pedram Nimreezi wrote:
> WebsiteContact is being referenced by one of your
> <foreign tags in one of your *.xml schemas...
>
> I may be wrong but I don't believe I am, hope that helps...
>
>
>
> On 10/1/06, Robert Bruce <rob at tdd dot org dot uk> wrote:
>> I have a system whereby I use a multi-component setup with propel, using
>> multiple schema files. Everything works fine for code generation and
>> installing the sql, however when I come to run a datadump an error
>> occurs regarding a missing table. The table does exist in the database,
>> but I believe the error is due to the schema files not been processed in
>> dependency order.
>>
>> Here is an output from attempting to run the datadump target
>>
>> http://www.tdd.org.u​k:81/propel.txt
>>
>> If you look at the order the schema files are processed the first file
>> licencing.schema.xml depends on the schema website.schema.xml which is
>> being processed further down the list. Is there any way can control the
>> order in which the schema files are processed? Or is there any other way
>> to get around this problem?
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>>
>
>
> --
> ~
> Pedram Nimreezi -- President/Senior Engineer
> Major Computing, Inc
> --
>
> Not by age, but by knowledge is wisdom acquired.
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] datadump across multiple schema files

Reply

Author Pedram Nimreezi <zenstyle at gmail dot com>
Full name Pedram Nimreezi <zenstyle at gmail dot com>
Date 2006-10-02 05:20:03 PDT
Message WebsiteContact is being referenced by one of your
<foreign tags in one of your *.xml schemas...

I may be wrong but I don't believe I am, hope that helps...



On 10/1/06, Robert Bruce <rob at tdd dot org dot uk> wrote:
> I have a system whereby I use a multi-component setup with propel, using
> multiple schema files. Everything works fine for code generation and
> installing the sql, however when I come to run a datadump an error
> occurs regarding a missing table. The table does exist in the database,
> but I believe the error is due to the schema files not been processed in
> dependency order.
>
> Here is an output from attempting to run the datadump target
>
> http://www.tdd.org.u​k:81/propel.txt
>
> If you look at the order the schema files are processed the first file
> licencing.schema.xml depends on the schema website.schema.xml which is
> being processed further down the list. Is there any way can control the
> order in which the schema files are processed? Or is there any other way
> to get around this problem?
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>


--
~
Pedram Nimreezi -- President/Senior Engineer
Major Computing, Inc
--

Not by age, but by knowledge is wisdom acquired.

Re: [propel-dev] datadump across multiple schema files

Reply

Author Luciano Andrade <andrade dot luciano at gmail dot com>
Full name Luciano Andrade <andrade dot luciano at gmail dot com>
Date 2006-10-02 04:25:44 PDT
Message Ovbiusly you could try to renameit to some ting like
01Website.schema.xml 02Licencing.schema.xml

But I realy don´t understend how the multi-schema definition works
when you reference tables/relations from others schemas.

On 10/1/06, Robert Bruce <rob at tdd dot org dot uk> wrote:
> I have a system whereby I use a multi-component setup with propel, using
> multiple schema files. Everything works fine for code generation and
> installing the sql, however when I come to run a datadump an error
> occurs regarding a missing table. The table does exist in the database,
> but I believe the error is due to the schema files not been processed in
> dependency order.
>
> Here is an output from attempting to run the datadump target
>
> http://www.tdd.org.u​k:81/propel.txt
>
> If you look at the order the schema files are processed the first file
> licencing.schema.xml depends on the schema website.schema.xml which is
> being processed further down the list. Is there any way can control the
> order in which the schema files are processed? Or is there any other way
> to get around this problem?
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

datadump across multiple schema files

Reply

Author Robert Bruce <rob at tdd dot org dot uk>
Full name Robert Bruce <rob at tdd dot org dot uk>
Date 2006-10-01 14:28:38 PDT
Message I have a system whereby I use a multi-component setup with propel, using
multiple schema files. Everything works fine for code generation and
installing the sql, however when I come to run a datadump an error
occurs regarding a missing table. The table does exist in the database,
but I believe the error is due to the schema files not been processed in
dependency order.

Here is an output from attempting to run the datadump target

http://www.tdd.org.u​k:81/propel.txt

If you look at the order the schema files are processed the first file
licencing.schema.xml depends on the schema website.schema.xml which is
being processed further down the list. Is there any way can control the
order in which the schema files are processed? Or is there any other way
to get around this problem?

Re: [propel-dev] New Transaction setup

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-10-01 06:18:15 PDT
Message I have committed a modified version of this patch to 1.3, which we can
port to 2.0. It does not modify the PDO method signatures; it simply
allows nested transactions to be invoked without throwing an exception
-- or doing anything (the same functionality of the Transaction class).

Hans

Cameron Brunner wrote:
> What was the verdict about doing this in 2.0? Have you got something
> ready or should i commit what i have done or ?
>
>
> Cameron
>
> On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
>> Ok, well, I wasn't planning on changing anything about the behavior of
>> the PDO API except the fact that it throws an exception when you
>> beginTransaction() within another transaction. Or provide a
>> isInTransaction() method or something ...
>>
>> Hans
>>
>> Cameron Brunner wrote:
>> > I was trying to avoid altering the default pdo functionality, i just
>> > wanted to add what we needed for propel so when users used the
>> > connection directly it was 'as normal'...
>> >
>> >
>> > Cameron
>> >
>> > On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
>> >> I spend some more time looking at this & at PDO. I'm going to
>> commit a
>> >> slightly modified version of this to 1.3 branch (and later, to
>> trunk) --
>> >> so that API matches default PDO as possible.
>> >>
>> >> Thanks!
>> >>
>> >> Hans
>> >>
>> >> Hans Lellelid wrote:
>> >> > Hi Cameron,
>> >> >
>> >> > I just had an opportunity to look at this patch. I hadn't thought
>> >> about
>> >> > simply extending the PDO class. Were the
>> begin()/rollback()/commit()
>> >> > methods final (i.e. is that why you created txnBegin(), etc.)?
>> >> >
>> >> > I'd rather use an API that will allow us to revert to using the
>> >> default
>> >> > PDO driver, once its transaction support is improved.
>> >> >
>> >> > Hans
>> >> >
>> >> > Cameron Brunner wrote:
>> >> >
>> >> >> This needs a beating before it gets commited however i extended
>> PDO
>> >> >> and setup a transaction wrapper in it and altered the
>> generators to
>> >> >> use it. Anyone care to try it out and let me know how it goes for
>> >> >> them? Also does anyone have any objections to a patch along these
>> >> >> lines? I have it active on my sites and it seems fine...
>> >> >>
>> >> >>
>> >> >> Cameron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

Re: [propel-dev] New Transaction setup

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-10-01 01:45:32 PDT
Message What was the verdict about doing this in 2.0? Have you got something
ready or should i commit what i have done or ?


Cameron

On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
> Ok, well, I wasn't planning on changing anything about the behavior of
> the PDO API except the fact that it throws an exception when you
> beginTransaction() within another transaction. Or provide a
> isInTransaction() method or something ...
>
> Hans
>
> Cameron Brunner wrote:
> > I was trying to avoid altering the default pdo functionality, i just
> > wanted to add what we needed for propel so when users used the
> > connection directly it was 'as normal'...
> >
> >
> > Cameron
> >
> > On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
> >> I spend some more time looking at this & at PDO. I'm going to commit a
> >> slightly modified version of this to 1.3 branch (and later, to trunk) --
> >> so that API matches default PDO as possible.
> >>
> >> Thanks!
> >>
> >> Hans
> >>
> >> Hans Lellelid wrote:
> >> > Hi Cameron,
> >> >
> >> > I just had an opportunity to look at this patch. I hadn't thought
> >> about
> >> > simply extending the PDO class. Were the begin()/rollback()/commit()
> >> > methods final (i.e. is that why you created txnBegin(), etc.)?
> >> >
> >> > I'd rather use an API that will allow us to revert to using the
> >> default
> >> > PDO driver, once its transaction support is improved.
> >> >
> >> > Hans
> >> >
> >> > Cameron Brunner wrote:
> >> >
> >> >> This needs a beating before it gets commited however i extended PDO
> >> >> and setup a transaction wrapper in it and altered the generators to
> >> >> use it. Anyone care to try it out and let me know how it goes for
> >> >> them? Also does anyone have any objections to a patch along these
> >> >> lines? I have it active on my sites and it seems fine...
> >> >>
> >> >>
> >> >> Cameron

Re: [propel-dev] New Transaction setup

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-22 09:01:57 PDT
Message Ok, well, I wasn't planning on changing anything about the behavior of
the PDO API except the fact that it throws an exception when you
beginTransaction() within another transaction. Or provide a
isInTransaction() method or something ...

Hans

Cameron Brunner wrote:
> I was trying to avoid altering the default pdo functionality, i just
> wanted to add what we needed for propel so when users used the
> connection directly it was 'as normal'...
>
>
> Cameron
>
> On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
>> I spend some more time looking at this & at PDO. I'm going to commit a
>> slightly modified version of this to 1.3 branch (and later, to trunk) --
>> so that API matches default PDO as possible.
>>
>> Thanks!
>>
>> Hans
>>
>> Hans Lellelid wrote:
>> > Hi Cameron,
>> >
>> > I just had an opportunity to look at this patch. I hadn't thought
>> about
>> > simply extending the PDO class. Were the begin()/rollback()/commit()
>> > methods final (i.e. is that why you created txnBegin(), etc.)?
>> >
>> > I'd rather use an API that will allow us to revert to using the
>> default
>> > PDO driver, once its transaction support is improved.
>> >
>> > Hans
>> >
>> > Cameron Brunner wrote:
>> >
>> >> This needs a beating before it gets commited however i extended PDO
>> >> and setup a transaction wrapper in it and altered the generators to
>> >> use it. Anyone care to try it out and let me know how it goes for
>> >> them? Also does anyone have any objections to a patch along these
>> >> lines? I have it active on my sites and it seems fine...
>> >>
>> >>
>> >> Cameron
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>

Re: [propel-dev] New Transaction setup

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-22 08:33:32 PDT
Message I was trying to avoid altering the default pdo functionality, i just
wanted to add what we needed for propel so when users used the
connection directly it was 'as normal'...


Cameron

On 9/23/06, Hans Lellelid <hans at velum dot net> wrote:
> I spend some more time looking at this & at PDO. I'm going to commit a
> slightly modified version of this to 1.3 branch (and later, to trunk) --
> so that API matches default PDO as possible.
>
> Thanks!
>
> Hans
>
> Hans Lellelid wrote:
> > Hi Cameron,
> >
> > I just had an opportunity to look at this patch. I hadn't thought about
> > simply extending the PDO class. Were the begin()/rollback()/commit()
> > methods final (i.e. is that why you created txnBegin(), etc.)?
> >
> > I'd rather use an API that will allow us to revert to using the default
> > PDO driver, once its transaction support is improved.
> >
> > Hans
> >
> > Cameron Brunner wrote:
> >
> >> This needs a beating before it gets commited however i extended PDO
> >> and setup a transaction wrapper in it and altered the generators to
> >> use it. Anyone care to try it out and let me know how it goes for
> >> them? Also does anyone have any objections to a patch along these
> >> lines? I have it active on my sites and it seems fine...
> >>
> >>
> >> Cameron

Re: [propel-dev] New Transaction setup

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-22 08:19:53 PDT
Message I spend some more time looking at this & at PDO. I'm going to commit a
slightly modified version of this to 1.3 branch (and later, to trunk) --
so that API matches default PDO as possible.

Thanks!

Hans

Hans Lellelid wrote:
> Hi Cameron,
>
> I just had an opportunity to look at this patch. I hadn't thought about
> simply extending the PDO class. Were the begin()/rollback()/commit()
> methods final (i.e. is that why you created txnBegin(), etc.)?
>
> I'd rather use an API that will allow us to revert to using the default
> PDO driver, once its transaction support is improved.
>
> Hans
>
> Cameron Brunner wrote:
>
>> This needs a beating before it gets commited however i extended PDO
>> and setup a transaction wrapper in it and altered the generators to
>> use it. Anyone care to try it out and let me know how it goes for
>> them? Also does anyone have any objections to a patch along these
>> lines? I have it active on my sites and it seems fine...
>>
>>
>> Cameron
>> --------------------​--------------------​--------------------​------------
>>
>> --------------------​--------------------​--------------------​---------
>> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
>> For additional commands, e-mail: dev-help at propel dot tigris dot org
>>
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org
>
>

Re: [propel-dev] New Transaction setup

Reply

Author hlellelid
Full name Hans Lellelid
Date 2006-09-22 08:08:39 PDT
Message Hi Cameron,

I just had an opportunity to look at this patch. I hadn't thought about
simply extending the PDO class. Were the begin()/rollback()/commit()
methods final (i.e. is that why you created txnBegin(), etc.)?

I'd rather use an API that will allow us to revert to using the default
PDO driver, once its transaction support is improved.

Hans

Cameron Brunner wrote:
> This needs a beating before it gets commited however i extended PDO
> and setup a transaction wrapper in it and altered the generators to
> use it. Anyone care to try it out and let me know how it goes for
> them? Also does anyone have any objections to a patch along these
> lines? I have it active on my sites and it seems fine...
>
>
> Cameron
> --------------------​--------------------​--------------------​------------
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> For additional commands, e-mail: dev-help at propel dot tigris dot org

New Transaction setup

Reply

Author Cameron Brunner <cameron dot brunner at gmail dot com>
Full name Cameron Brunner <cameron dot brunner at gmail dot com>
Date 2006-09-17 22:00:43 PDT
Message This needs a beating before it gets commited however i extended PDO
and setup a transaction wrapper in it and altered the generators to
use it. Anyone care to try it out and let me know how it goes for
them? Also does anyone have any objections to a patch along these
lines? I have it active on my sites and it seems fine...


Cameron
Attachments
Messages per page: