Got it thanks
Le 08/01/2018 à 18:15, Scott Gray a écrit :
The argument was that the configs weren't being used by default, so the
same would, in theory, apply to those files.
Regards
Scott
On 9/01/2018 5:14 AM, "Jacques Le Roux"
wrote:
Le 08/01/2018 à 01:36, Scott Gray a écrit :
The same g
The argument was that the configs weren't being used by default, so the
same would, in theory, apply to those files.
Regards
Scott
On 9/01/2018 5:14 AM, "Jacques Le Roux"
wrote:
Le 08/01/2018 à 01:36, Scott Gray a écrit :
> The same goes for the fieldtype definitions.
>
I agree with you for en
Le 08/01/2018 à 01:36, Scott Gray a écrit :
The same goes for the fieldtype definitions.
I agree with you for entityengine.xml, but those are separated, so I don't see
the relationship.
Jacques
+1
Michael
Am 08.01.18 um 01:36 schrieb Scott Gray:
I'm in favor of the status quo. It's useful to have them available out of
the box to be able to pick the one you need and proceed without having to
look elsewhere. The same goes for the fieldtype definitions.
Regards
Scott
On 8/01/2018 6:26
I'm in favor of the status quo. It's useful to have them available out of
the box to be able to pick the one you need and proceed without having to
look elsewhere. The same goes for the fieldtype definitions.
Regards
Scott
On 8/01/2018 6:26 AM, "Pierre Smits" wrote:
We could consider having ex
We could consider having example configurations (entityengine.xml files)
for applicable database solutions in the documentation (in confluence).
Removing unused code snippets is always worth the effort put forward.
Best regards,
Pierre Smits
V.P. Apache Trafodion
On Sun, Jan 7, 2018 at 5:36
Le 07/01/2018 à 11:43, Jacques Le Roux a écrit :
My answer to your question is: we should keep them of course, except if a
better way would be proposed, I see none for now...
I must have said: I see none PROVIDED for now...
We could consider a modular solution which would include split parts o
Hi everyone,
Only did a quick look at the 2 patches.
I think the improvement is incomplete and effectively removed the datasource
configurations like MSSQL, MySQL, Oracle etc. Developers (like me) using these
databases will require additional work to find and apply the missing
configurations.
Michael,
We crossed on wire. I put a comment just after yours in the Jira it's not an
answer to your questions but my thoughts at large.
My answer to your question is: we should keep them of course, except if a
better way would be proposed, I see none for now...
Jacques
Le 07/01/2018 à 11:3
Hi everyone,
please have a look at the issue mentioned below and express your
opionion if we should remove the different schema configurations from
the main entityengine.xml or if we should keep them.
Thanks,
Michael
Am 07.01.18 um 11:23 schrieb Pierre Smits (JIRA):
[
https://issues
10 matches
Mail list logo