hi udai

Hi ralf

I saw your patch

I merged the changes in my workspace and created new patch for the implementation

you can see that on issue-2442

have you understood the changes

yes

using those only I was able to create the implementation for conditions

I didn't thought about implementing field in AbstractField

which solved the problem

before checking the patch you can go through the comment and we can discuss

checking my mailbox at the moment

while a like your idea to maipulate conditions this will not work in all cases

not (o.name is null) -> (o.name is not null): very good

but how about

not ((o.name is null) or (o.name="foo"))

so I think we can keep both

this can be transformed to (o.name is not null) and (o.name<>"foo")

but this transformations can get quite tricky

the Not object and boolean _not in Like,Between,In,Null

therefore i think we need Not but modify simple conditions as you suggested

yes thats why I haven't implemented not() yet in AbstractCondition

we have to implement it in the concrete condition

you mean CompoundCondition

oh no no ...sorry ..it was by mistake

nothing about CompoundCondition

I think you can check the Junit test

Junit test is not for everything yet...but I am working on that

also I am thinking that why you have created this InCondition interface

why didn't you interfaced IN and IS NULL as LIKE and BETWEEN

problem with IN is that you have to be able to add multiple items

but for the items not all expressions are allowed

path | parameter | literals

yes

and NULL

?

so instead of a factory method with List <Expression> i decided to use a special InCondition class that only has add methods for the types allowed

null is not allowed

@IN: okay ..got it

did you recognize that i defined Field as immutable and did not provide setters

why InCondition in() is in Field interface and not in Expression Interface

because EJB QL allows in only on fields but not on all expressions

@Field : ya but didn't know the reason

k

@IN: K

@ Field: why not setter

immutable means you can not change the object after construction

okay

because we don't need to change it when it ones created

for Field this isn't important yet but will get important later

k

when we implement validation of QO we will need to resolve type of the field

if one modifies name thereafter the resolved type doesn't match any more

so it's better to define it immutable

k

i think i'll do the same for literals and parameters

this will easy things later on

k

whyt's current state? you are working to finish conditions atm?

yes

I had few doubts which I wanted to clear before finalizing the things

what do you think how long this will take?

compair, Like and between are ready

in, null and not are remaining only

and the junit test to verify them

how about "and" and "or"?

they are also done

good

as I wasn't sure about not,in and null so I wanted to discuss before finalizing them

have you read my comment about TemporalType

yes

i thought of moving Field, Schema, Projection and some other from query.object.select to query objects package

what do you think?

I tested here every one of java.util and java.sql type that we talked

well I have no problem

@date: fine by me

@moving : no problem

@move: okay

@date: you know the interesting thing I found was they all store same data

all java.sql types extend java.util.Date

in milisec which is the standard they were all same ....like java.sql.Time() also has Date into it

yes

but I thought that Time will only have time

ya I learn that later that all these extends util.Date

I think for avoiding type conversion I can use util.Date only and drop the Idea of sql. types

then the only thing I need to care about is Calendar and Date conversion

i also think using java.util.Date would be a good idea

at review of your previous work i sometimes recognized varying idention

like?

and i also had to improve javadoc in some cases

I will take care of those

i'll use minus instead of withespace to highlight

if (condition) {

----// do something

-}

or something like that

k

as you said everything is included in latest patch

and you do only changes to condition package atm

few things in function

and implementation in AbstractExpression of expression package

small change in OrderDirection

okay i then leave function, expression and condition unchanged

having said that i will be away from time to time to watch what happens in F1 race

k

I will try to finish things ASAP

okay

I will go to market for like at most one hour

so I will be out till then

okay. see you later

see you

Hi ralf

I am sorry there was some power problem here

hi udai

@power: that may happen

sorry, had been away of pc for a while

I have complited In, Not and Null

now just creating Junit tests for all

very good

i had some problems to merge your latest patch

like??

the patch included only parts of the whole project and some did not include my last patch from select package

but I think I have included the select package in patch

i suggest you to change only one package and include all classes of this package in patch

this makes it much easier to merge our changes

i do not change anything at condition, expression and function package

pardon, I didn't got you......what was missing in last patch

so you can do changes at this packages

my changes to class in select package

but don't care about the past

oh sorry for that

it includes the previous select package

yes

although I am working on your implementation changes

as i told you earlier today i do changes to the other packages

so i will only merge your changes to conditon, expression and function

i will throw away every other change when merging

when i talk about condition, expression and function i mean main and test parts

okay

ralf, how function are supposed to be used via Expression interface

I mean could you give me an example

schema.field(name).length()

schema.field(name).length().greaterThan(10)

I mean this will return Function

udai: i'm out now. I plan to continue work at QO tomorrow evening

bye

k

see you tomorrow