[Modeling-users] Query bug when not using ec.saveChanges

[Ernesto Revilla]

Dear all,

just a question: can't I fetch objects by attribute access, without
having used ec.saveChanges first? See the last 4 lines of the following
source code. What restrictions exist using fetch, in respect with
ec.saveChanges?

Thanx,
Erny


"""
A simple model
+-------+ 1 0,* +--------+ 1 0,* +-------------+
| Hotel |<-hotel------rooms->>| Room |<-room-----reservations->>| Reservation |
+-------+ nullify cascade +--------+ nullify cascade +-------------+
| name | | number | | startDay |
+-------+ +--------+ | endDay |
+-------------+
"""

from Modeling.PyModel import *

# valores por defecto para el modelo
Attribute.defaults['usedForLocking']=1
AString.defaults['externalType']='TEXT'
AString.defaults['width'] = 0
AString.defaults['usedForLocking']=1

Association.defaults['delete']=['nullify', 'nullify']

Entity.defaults['properties'] = [
APrimaryKey('id', isClassProperty=0, isRequired=1, doc='PK')
]

_connDict = {'database': 'reservations.sqlite'}
model = Model('Reservations',adaptorName='SQLite', connDict=_connDict, version='0.1')
model.doc=__doc__

model.entities = [
Entity('Hotel',
properties=[ AString('name', isRequired=1),
],
),

Entity('Room',
properties=[ AInteger('number', isRequired=1),
]
),

Entity('Reservation',
properties=[
ADateTime('startDay', isRequired=1),
ADateTime('endDay', isRequired=1),
]
),
]

# Associations will allways be defined towards the 'one' part.
model.associations = [
Association('Reservation', 'Room', relations=['room','reservations'],
multiplicity=[ [1, 1] , [0, None] ],
delete=['nullify','cascade']),
Association('Room', 'Hotel', relations=['hotel','rooms'],
multiplicity=[ [1, 1] , [0, None] ],
delete=['nullify','deny']),
]

model.build()


def test():
from Modeling.EditingContext import EditingContext
from mx.DateTime import Date, Time
from Reservations.Hotel import Hotel
from Reservations.Room import Room
from Reservations.Reservation import Reservation
ec=EditingContext()
h=ec.fetch('Hotel','name == "Ritz"') #!!! tiene q ser "Ritz" no 'Ritz'
if not h:
h=Hotel(name="Ritz"); ec.insert(h)
ec.saveChanges()
else:
h=h[0]
r=ec.fetch('Room','number == 101')
if not r:
r=Room(number=101); ec.insert(r)
r.setHotel(h)
ec.saveChanges()
else:
r=r[0]

res=Reservation()
ec.insert(res)
res.setRoom(r); r.addToReservations(res)
res.setStartDay(Date(2004,8,9)); res.setEndDay(Date(2004,8,14))

# ec.saveChanges()

## This does return an instance in each case
res=ec.fetch("Reservation",'startDay like "2004-08-09*"')
print "res normal fetch:",res


## !!! without ec.saveChanges this does return None !!!
res=ec.fetch("Room",'reservations.startDay like "2004-08-09*"')
print "res fetch with attribute traversal:",res




---
avast! Antivirus: Saliente mensaje limpio.
Base de datos de Virus (VPS): 0433-1, 09/08/2004
Comprobado en: 10/08/2004 18:30:15
avast! tiene los derechos reservados (c) 2000-2004 ALWIL Software.
http://www.avast.com

[Sebastien Bigaret]

Post by Ernesto Revilla
Dear all,
just a question: can't I fetch objects by attribute access, without
having used ec.saveChanges first? See the last 4 lines of the
following source code. What restrictions exist using fetch, in respect
with ec.saveChanges?
Thanx,
Erny

[example snipped]

To be perfectly clear: there should not exist such a restriction.

I'm currently away from any development environment, with an access to my emails
but that's all, so I'm not able to check and diagnose this. You have found a
bug for sure --even if, for now, I cannot be completely positive about the fact
that it can be easily solved.

Anyhow, thanks for reporting! may I ask you to fill a bug report? I'll get
back to you next week (I can't say exactly when, I'll be extremely busy for the
10 coming days).

In case you're in a hurry, you may want to check this by yourself by checking
EditingContext.fetch(): at the end of it, it applies the qualifier (here,
'reservations.startDay like "2004-08-09*"') to its inserted objects of the
correct type/entity. I suspect that you get no objects because the 'like'
operator tries to compare a string to a Date object, which obviously never
selects any object.

If this is the case, then the solution is probably to check the type of the
destination attribute (startDay), and, if it is a date, then adjust the
qualifier's value accordingly (may be changing the operator from 'like' to
'between'); or an other (more efficient?) solution could be to compare the
string with the string representation of the attribute's value... but this
would add the constraint that such a string representation should be the same
than the database's representation for dates...

Oh well, anyhow, you get the idea, don't you?-) I'm pretty confident that the
bug is only triggered with attributes whose type is Date.

-- Sébastien.

[Lorenzo Gil Sanchez]

Post by Sebastien Bigaret
Anyhow, thanks for reporting! may I ask you to fill a bug report? I'll get
back to you next week (I can't say exactly when, I'll be extremely busy for the
10 coming days).

I will fill the bug (since it also happened to me)

Regards

Lorenzo Gil