Select with wrong number of columns

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Select with wrong number of columns

Abel Armoa
Hello everyone:

I am writing you today because I am experiencing an odd behavior during a select with Glorp. I am currently using VA Smalltalk 8.6.1.

I have the following classes:

TRADE
sequentialNumber
amount
price (references a Price)

PRICE 
every (references a Measurement)
money (references a Measurement)

MEASUREMENT
amount
unit 

Measurement is mapped to an imaginary table:
IMAGINARY_MEASUREMENT_TABLE
amount
unit

Price is also mapped to an imaginary table:
IMAGINARY_PRICE_TABLE
every_amount
every_unit
money_amount
money_unit
The descriptor for Price is configured with two EmbeddedValueOneToOneMapping, each of them with one Join. The first one maps the every_amount field of IMAGINARY_PRICE_TABLE with the amount field of IMAGINARY_MEASUREMENT_TABLE, and the every_unit field of IMAGINARY_PRICE_TABLE to the unit field of IMAGINARY_MEASUREMENT_TALE. The second one does the same, but with the fields money_amount and money_unit.

Finally, the Trade class is mapped to a real table:
TRADE_TABLE
sequential_number
amount
price_every_amount
price_every_unit
price_money_amount
price_money_unit
Here again I am using a EmbeddedValueOneToOneMapping with a Join, that mapps the field form the IMAGINARY_PRICE_TABLE to this table (using the fields price_every_amount, price_every_unit, price_money_amount, price_money_unit).

The problem I am experiencing arises when I try to execute a Query that looks for all the Trades with a price that has its money part expressed in a unit in particular. The select that Glorp is building has all the columns of TRADE_TABLE, but it is also adding the columns form IMAGINARY_PRICE_TABLE, like this:

SELECT t1.sequential_number, t1.amount, t1.price_every_amount, t1.price_every_unit, t1.price_money_amount, t1.price_money_unit, t1.every_amount, t1.every_unit, t1.money_amount, t1.money_unit 
FROM t1.TRADE_TABLE ...

But the columns every_amount, every_unit, money_amount, money_unit don't exist in the TRADE_TABLE.

I found a way to make it work, which was naming the columns in TRADE_TABLE used to persist the information about the price with the same names of the fields in IMAGINARY_PRICE_TABLE. But this is a patch rather than a solution, and is keeping me from persisting trades that reference more than one price.

If someone has any idea about what might be wrong, I would really appreciate the help.

Thank you very much,
Abel Armoa


 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Select with wrong number of columns

Alan Knight-2
Hmm. I think that ought to work.

So at the object level, you have Trade, which has an embedded mapping to a Price, and you give it a join that maps the fields. But a Price itself has two embedded mappings, to Measurements. It's been a while since I've looked at those, but I think that case is pretty similar to what's used in the tests, and it ought to cover that. But it's possible that in the tests we happened to use the same field names, so it worked like your workarounds. I'm not sure. But I would say your best bet is to look at the tests and see if it's doing anything different.

I would think that possibly, because there are two levels of embedded (Trade-Price and Price->Measurement) that you might have to have that as two different joins. But I could be wrong, and it's not immediately obvious how you'd specify that.



On Wed Jan 28 2015 at 8:52:11 AM Abel Armoa <[hidden email]> wrote:
Hello everyone:

I am writing you today because I am experiencing an odd behavior during a select with Glorp. I am currently using VA Smalltalk 8.6.1.

I have the following classes:

TRADE
sequentialNumber
amount
price (references a Price)

PRICE 
every (references a Measurement)
money (references a Measurement)

MEASUREMENT
amount
unit 

Measurement is mapped to an imaginary table:
IMAGINARY_MEASUREMENT_TABLE
amount
unit

Price is also mapped to an imaginary table:
IMAGINARY_PRICE_TABLE
every_amount
every_unit
money_amount
money_unit
The descriptor for Price is configured with two EmbeddedValueOneToOneMapping, each of them with one Join. The first one maps the every_amount field of IMAGINARY_PRICE_TABLE with the amount field of IMAGINARY_MEASUREMENT_TABLE, and the every_unit field of IMAGINARY_PRICE_TABLE to the unit field of IMAGINARY_MEASUREMENT_TALE. The second one does the same, but with the fields money_amount and money_unit.

Finally, the Trade class is mapped to a real table:
TRADE_TABLE
sequential_number
amount
price_every_amount
price_every_unit
price_money_amount
price_money_unit
Here again I am using a EmbeddedValueOneToOneMapping with a Join, that mapps the field form the IMAGINARY_PRICE_TABLE to this table (using the fields price_every_amount, price_every_unit, price_money_amount, price_money_unit).

The problem I am experiencing arises when I try to execute a Query that looks for all the Trades with a price that has its money part expressed in a unit in particular. The select that Glorp is building has all the columns of TRADE_TABLE, but it is also adding the columns form IMAGINARY_PRICE_TABLE, like this:

SELECT t1.sequential_number, t1.amount, t1.price_every_amount, t1.price_every_unit, t1.price_money_amount, t1.price_money_unit, t1.every_amount, t1.every_unit, t1.money_amount, t1.money_unit 
FROM t1.TRADE_TABLE ...

But the columns every_amount, every_unit, money_amount, money_unit don't exist in the TRADE_TABLE.

I found a way to make it work, which was naming the columns in TRADE_TABLE used to persist the information about the price with the same names of the fields in IMAGINARY_PRICE_TABLE. But this is a patch rather than a solution, and is keeping me from persisting trades that reference more than one price.

If someone has any idea about what might be wrong, I would really appreciate the help.

Thank you very much,
Abel Armoa


 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Select with wrong number of columns

Abel Armoa
Thank you very much for your reply Alan.
I will look at the tests again.

A friend of mine also told me that I should try mapping the measurements using the ad-hoc mapping. I think that is a really good idea.

Thanks again for your help,
Abel Armoa

On Wed, Jan 28, 2015 at 3:20 PM, Alan Knight <[hidden email]> wrote:
Hmm. I think that ought to work.

So at the object level, you have Trade, which has an embedded mapping to a Price, and you give it a join that maps the fields. But a Price itself has two embedded mappings, to Measurements. It's been a while since I've looked at those, but I think that case is pretty similar to what's used in the tests, and it ought to cover that. But it's possible that in the tests we happened to use the same field names, so it worked like your workarounds. I'm not sure. But I would say your best bet is to look at the tests and see if it's doing anything different.

I would think that possibly, because there are two levels of embedded (Trade-Price and Price->Measurement) that you might have to have that as two different joins. But I could be wrong, and it's not immediately obvious how you'd specify that.



On Wed Jan 28 2015 at 8:52:11 AM Abel Armoa <[hidden email]> wrote:
Hello everyone:

I am writing you today because I am experiencing an odd behavior during a select with Glorp. I am currently using VA Smalltalk 8.6.1.

I have the following classes:

TRADE
sequentialNumber
amount
price (references a Price)

PRICE 
every (references a Measurement)
money (references a Measurement)

MEASUREMENT
amount
unit 

Measurement is mapped to an imaginary table:
IMAGINARY_MEASUREMENT_TABLE
amount
unit

Price is also mapped to an imaginary table:
IMAGINARY_PRICE_TABLE
every_amount
every_unit
money_amount
money_unit
The descriptor for Price is configured with two EmbeddedValueOneToOneMapping, each of them with one Join. The first one maps the every_amount field of IMAGINARY_PRICE_TABLE with the amount field of IMAGINARY_MEASUREMENT_TABLE, and the every_unit field of IMAGINARY_PRICE_TABLE to the unit field of IMAGINARY_MEASUREMENT_TALE. The second one does the same, but with the fields money_amount and money_unit.

Finally, the Trade class is mapped to a real table:
TRADE_TABLE
sequential_number
amount
price_every_amount
price_every_unit
price_money_amount
price_money_unit
Here again I am using a EmbeddedValueOneToOneMapping with a Join, that mapps the field form the IMAGINARY_PRICE_TABLE to this table (using the fields price_every_amount, price_every_unit, price_money_amount, price_money_unit).

The problem I am experiencing arises when I try to execute a Query that looks for all the Trades with a price that has its money part expressed in a unit in particular. The select that Glorp is building has all the columns of TRADE_TABLE, but it is also adding the columns form IMAGINARY_PRICE_TABLE, like this:

SELECT t1.sequential_number, t1.amount, t1.price_every_amount, t1.price_every_unit, t1.price_money_amount, t1.price_money_unit, t1.every_amount, t1.every_unit, t1.money_amount, t1.money_unit 
FROM t1.TRADE_TABLE ...

But the columns every_amount, every_unit, money_amount, money_unit don't exist in the TRADE_TABLE.

I found a way to make it work, which was naming the columns in TRADE_TABLE used to persist the information about the price with the same names of the fields in IMAGINARY_PRICE_TABLE. But this is a patch rather than a solution, and is keeping me from persisting trades that reference more than one price.

If someone has any idea about what might be wrong, I would really appreciate the help.

Thank you very much,
Abel Armoa


 

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "glorp-group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/glorp-group.
For more options, visit https://groups.google.com/d/optout.
Loading...