gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnue-dev] a sample GNUe Mapping Definition


From: Jan Ischebeck
Subject: Re: [Gnue-dev] a sample GNUe Mapping Definition
Date: Sun, 17 Nov 2002 19:31:01 +0100
User-agent: KMail/1.4.3

Jason, thank you for the good questions.

I try to answer/comment inline.

Am Donnerstag, 14. November 2002 01:16 schrieb Jason Cater:
> Jan, a few questions:
>
> 1. What is the purpose of <input> and <output> ??
The idea was to differentiate between between datasources used for loading and 
storing data: But it seems to be better to just define datasources in a 
header and then just use them in the mapping.

>
> 2. Why a separate <process> tag? Why not keep it part of <mapping>.
> Isn't <mapping> defining a single process/map/transaction?
>
I wanted to differentiate between logical and technical grouping. Different 
mappings shouldn't have any relations, but processes in a mapping could be 
related. Process definition would be grouped together, if f.e. a table need 
to be processed twice. This would also include, that if there are errors 
occuring during a process, then all other processes in the mapping would need 
to ROLLBACK (that would depend on some kind of integrity setting).

> 3. Do you think <merge> and <split> leave enough flexibility? How would
> you handle getting:
>
>    Memphis, TN 38117
>
> into city, state, zip? I assume a trigger of some sort.

It could be solved with a double split. But that would just make sense if the 
data is allways correct. 

>
> 4. Aren't merges, splits too different from one situation to the next to
> try to define a tag for them? Perhaps merges and splits should be
> handled only by triggers? 

I don't think that we should require people to write trigger even for so 
simple actions. The very basic mapping stuff should be possible without any 
triggers. 

>                          Otherwise we'll end up with tons of "options"
> to the <merge> and <split> tags. I'm torn on this one.

What about moving copy, merge, split etc. into one action tag:

<action type="copy|merge|split" parameters="">
  <field type="src" name="" datasource="">
  <field type="dest" name="" datasource="">   
<action>


> 5. How will this handle "un-formatting" data? e.g., I have a lot of
> sources where they have the dollar fields as "$12.12". This, of course,
> needs to be converted to a numeric 12.12.   Dates and commified numbers
> are more good examples.
>
We could be using formatmasks for that (even if that would add more 
"options").
f.e. removing mask styles
<action type="un-mask" parameter="$%1">
  <field type="src" name="values_with_dollar" datasource="">   
  <field type="dest" name="justnumber" datasource="">      
</action>

<action type="mask" parameter="%1">
  <field type="src" name="values_with_dollar" datasource="">   
  <field type="dest" name="justnumber" datasource="">      
</action>

BTW. this mask stuff would make the split/merge thing unnecessary.
a merge would be something like <action type="un-mask" parameter="%1,%2,%3">

But especially the mask stuff would require additional parameter at row level
like how to handle not fiting input masks, like onerror="log and write|just 
log|rollback"

> Anyway, it's a start.
>
> -- Jason
>

Yes, it is.

  Jan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]