Yes, p6spy is exactly what I was looking for. Thanks for the hint :)
My idea evolved a little bit. Now I can initiate the import and log to a
file with the help of the p6spy driver. But I would like to not commit any
changes to the database.
I was thinking about starting a global transaction before importing the
pages to the DatabasePageManager and fire a rollback at the end. This can
also be configurable.
My problem is that I am not a Spring transaction specialist and I don’t
know how to correctly do this. Should I get the transactionManager from the
transaction.xml spring file? Would it impact the subsequent transactions as
I expect? If yes, do you have any piece of code to jumpstart me?
Thanks,
Seb
|---------------------------------------->
| Internet |
| [EMAIL PROTECTED] |
| |
| |
| 14/06/2007 13:11 |
| |
| |
| Veuillez répondre à |
| [EMAIL PROTECTED]|
| rg |
| |
|---------------------------------------->
>---------------------------------------------------------------------------------------------------------------|
|
|
|
|
|
Pour|
| jetspeed-user
|
|
cc|
|
|
|
Objet|
| Re: Réf. : Re: PSML import to sql scripts (populate)
|
|
|
|
|
|
|
|
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------|
[EMAIL PROTECTED] wrote:
> I was thinking about intercepting the sql generated by OJB to keep the
> multi database support. If I could find some sort of mock jdbc driver
that
> would give access to the generated sql it would help but I see two
problems
> with that solution:
>
> - Need some sort of logic to log only the delete/update/insert sql
and
> not the select sql done for reading the db
> - If I replace the JDBC driver with a mock one, the reference db will
> never be read for comparing
>
> Maybe by dividing the access to the datastore into two (reference
read-only
> data source, output data source) optionally configurable, then I could
> configure the output data source to log into a file with some sort of
mock
> driver.
>
> What do you think about this proposal?
Interesting :)
I think P6Spy, http://sourceforge.net/projects/p6spy/, might be what you
are looking for.
Its a dead project (no changes in the last 3 years), but I used it in the
past to track down database problems and it worked quite well.
Its also under ASF 1.1 license, so you could take that and adapt it to the
more dedicated and custom usage you need.
It also already provides nice configuration options for limiting logging to
certain tables etc. so it really could be a good match.
Note: I remember using a patched version myself because it didn't properly
handle PreparedStatement.setObject(...), so be aware of a few small bugs.
I don't have time to look at it right now, but if you could adapt it to a
dedicated Jetspeed-2 dml logger, I would definitely be happy to
add/integrate it in
Jetspeed :)
I can envision this to end up to a really nice solution indeed.
Good luck and keep us posted!
Regards,
Ate
> Seb
>
>
>
> |---------------------------------------->
> | Internet |
> | [EMAIL PROTECTED] |
> | |
> | |
> | 14/06/2007 12:13 |
> | |
> | |
> | Veuillez répondre à |
> | [EMAIL PROTECTED]|
> | rg |
> | |
> |---------------------------------------->
>
>---------------------------------------------------------------------------------------------------------------|
> |
|
> |
|
> |
Pour|
> | jetspeed-user
|
> |
cc|
> |
|
> |
Objet|
> | Re: PSML import to sql scripts (populate)
|
> |
|
> |
|
> |
|
> |
|
> |
|
> |
|
>
>---------------------------------------------------------------------------------------------------------------|
>
>
>
>
> [EMAIL PROTECTED] wrote:
>> Hi,
>>
>> Is there any way to configure the psml importer so that it will generate
>> sql scripts instead of updating live the database?
> No, not really.
> Because Jetspeed needs to support many different databases which use
> different sql formats, we actually are moving away from
> providing/generating sql...
> The only transportable solution we have is using intermediate xml and
> push/load that using a jdbc connection.
>
> I do understand your problem though, but I don't see an easy, generic and
> transparent solution for this.
> If you really need plain sql scripts, the only option I see right now is
> initial loading a developing database using the psml importer, and then
use
> a data dump
> tool/task usually provided with your database to generate the sql
scripts.
> But, if you can come up with a generic tool/solution for that which we
can
> integrate/provide (e.g. ASF license compatible) with Jetspeed, I'd be
happy
> to
> investigate/review that.
>
> Regards,
>
> Ate
>
>> Here in my project, we are planning to use Jetspeed to create our new
>> corporate portal. Jetspeed is fine for what we are trying to do but
there
>> is one point where I am not sure of the best solution.
>>
>> We are planning to develop the portal using xml psml files and migrate
to
>> the different environments by importing the psml into the database.
While
>> this is fine, the corporate habits here are to never use a program to
>> update a database and prefer to generate sql scripts, that you can
> review,
>> to do the populate job.
>>
>> If it is not supported, what would be the best and easiest way to
> implement
>> that feature? It is important enough for our project to implement this
> here
>> if necessary and I consider seriously contributing back.
>>
>> Thanks,
>> Seb
>>
>>
>> This message and any attachments (the "message") is
>> intended solely for the addressees and is confidential.
>> If you receive this message in error, please delete it and
>> immediately notify the sender. Any use not in accord with
>> its purpose, any dissemination or disclosure, either whole
>> or partial, is prohibited except formal approval. The internet
>> can not guarantee the integrity of this message.
>> BNP PARIBAS (and its subsidiaries) shall (will) not
>> therefore be liable for the message if modified.
>>
>> ---------------------------------------------
>>
>> Ce message et toutes les pieces jointes (ci-apres le
>> "message") sont etablis a l'intention exclusive de ses
>> destinataires et sont confidentiels. Si vous recevez ce
>> message par erreur, merci de le detruire et d'en avertir
>> immediatement l'expediteur. Toute utilisation de ce
>> message non conforme a sa destination, toute diffusion
>> ou toute publication, totale ou partielle, est interdite, sauf
>> autorisation expresse. L'internet ne permettant pas
>> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
>> filiales) decline(nt) toute responsabilite au titre de ce
>> message, dans l'hypothese ou il aurait ete modifie.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
