EmbeddedValueOneToOneMapping that returns nil when all embedded columns are nil

[jtuchel]

HI again,

I've been using Glorp quiet happily for a few months, you can see that in the frequency of posts to this forum ;-)

But now I have a question.

I am using an EmbeddedValueOneToOneMapping to map two date columns to a TimeSpan- or Period-kind of Class (Zeitraum in German), which has a startDate and an endDate.

Here is an exaple mapping:

        (aDescriptor newMapping: EmbeddedValueOneToOneMapping)
        attributeName: #membershipPeriod;
        fieldTranslation: (
            (Join new)
                addSource: (table fieldNamed: 'membership_start')
                    target: ((self tableNamed: 'ZEITRAUM_EMBEDDED') fieldNamed: 'startDate');
                addSource: (table fieldNamed: 'membership_end')
                    target: ((self tableNamed: 'ZEITRAUM_EMBEDDED') fieldNamed: 'endDate');
                yourself).

This works great - until today. It seems I always only hat timespans that at least have a startDate. But now I need to use it for a table/class in which both start and end date can be NULL. In that case, I'd like to habe a #membershipPeriod of nil rather than a Period with both dates being nil.

I am sure there is some way to tell this embedded mapping to check such situations. I tried beOuterJoin, but that didn't help.

I hope I've explained my use case well and somebody here can help me

Joachim

[Annick]

Hi,

Have a look at the following (old) documentation for embedded values.

Annick

[jtuchel]

Hi Annick,

thanks for the document.

T've been using EmbeddedValueOneToOneMapping for a while now. The problem is that tehy always return an instance of the mapped class with nil variables in it instead of returning nil.

In the example from the document, you' always get an instance fo class Name which holds nil in its #first and #last instance variables. I'd like to get a nil instead of a Name object when both mapped attributes are nil...

Joachim

[Annick]

Hi Joachim,

I don't have any issues. When you modify the value, do you register both the embedding and the embedded object ?

[jtuchel]

Hi Annick,

I don't have any issues writing objects, I usually only register the embedding object and that saves both the embedding and the embedded object just fine.

The problem arises when reading objects back from the database and all columns that are mapped to an embedded object are NULL. Then I don't get a nil, but what I get is an instance of the class of the embedded object, all variables containing nil. I'd like to retrieve the whole embedded object as nil, however.

So in my example I can easily save objects containing a membership period as nil, which will result in NULL in both columns:  startDate  and endDate.

But when I read the embedding object back into Glorp, the membership period will always be a membershipPeriodObject with a startDate of nil and an endDate of Nil. What I'd be able to get bakc from the database is nil instead of a MembershipPeriod Instance.

Joachim

[jtuchel]

Coming back to this oldish thread, because I think I found some way to solve my problem: How to make sure that an Embedded Object that started its life as nil gets read back as nil from the Database.

I've written up what I did to accomplich it, and I think this is somewhat a not-yet-covered problem in Glorp Mappings. If you read to the end of my blog post, you'll see that Glorp is almost there, just the last few inches are missing, imo. So whether my "solution" is a solution or a workaround is probably something that can be argued about.

Anyways: here is how I solved my problem and a few thoughts about the whole problem: https://joachimtuchel.wordpress.com/2021/12/30/glorp-and-embedded-objects-now-nil-is-nil-and-why-not/

Maybe somebody working on Glorp would like to read it and comment if this should be solved as a configuration of an EmbeddedValueOneToOneMapping. I think it should, but maybe there are more open questions about how much granularity the definition of nillishness of an embedded objet should provide. OTOH: when queriying for nil, the definition seems to be clear anyways...

Joachim