Re: [Lift] Re: 1.1-M8 to 2.0-M1 behavior change

On Thu, Jan 21, 2010 at 1:24 AM, aw wrote: > I think I discovered that my issue is related to the fact that the > code is part of a CometActor/CometListener, and it sounds like S isn't > fully functional from this perspective... My clue was the > inStatefulScope_? method documentation. > > I do

[Lift] Re: 1.1-M8 to 2.0-M1 behavior change

I think I discovered that my issue is related to the fact that the code is part of a CometActor/CometListener, and it sounds like S isn't fully functional from this perspective... My clue was the inStatefulScope_? method documentation. I do think I managed to work around my specific issue, but I

[Lift] Re: 1.1: children of menu items do not appear

Tim, thanks again for the reply. I did clean out the old code. In 1.1 I've hit the bug, I think. I found the reason why it did not work with 2.0. I had to use expandAll and had to adjust the css for the menu. It's working fine now. Thanks guys! Joachim On Jan 16, 6:15 pm, Tim Nelson wrote: > D

Re: [Lift] Re: 1.1: children of menu items do not appear

Try: mvn -U clean jetty:run Cheers, Tim On 16 Jan 2010, at 17:15, Tim Nelson wrote: > Did you "clean" out your code before you updated? I don't use maven, > so I'm not sure of the exact command, but that seems to come up a lot > on this list. > > If you indeed did clean out the code before upd

Re: [Lift] Re: 1.1: children of menu items do not appear

Did you "clean" out your code before you updated? I don't use maven, so I'm not sure of the exact command, but that seems to come up a lot on this list. If you indeed did clean out the code before updating, then I'm afraid I'm not sure how to help you further. I've only used mappper a little and c

[Lift] Re: 1.1: children of menu items do not appear

Tim, thank you for your reply. I've updated updated to 2.0-SNAPSHOT now. The submenu items still do not appear, though. Do I need to set some options or is it still the bug you mentioned? Regards, Joachim On Jan 16, 4:36 pm, Tim Nelson wrote: > There was a bug that's been fixed. I suggest you u

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

On Thu, Nov 5, 2009 at 3:47 PM, jon wrote: > > I just verified that the newer h2 fixes the problem. Thanks for > investigating! > Sure thing. Party on! > > On Nov 5, 6:33 pm, David Pollak wrote: > > On Wed, Nov 4, 2009 at 10:02 AM, jon wrote: > > > > > Hi, > > > > > I just noticed OrderBy

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

I just verified that the newer h2 fixes the problem. Thanks for investigating! On Nov 5, 6:33 pm, David Pollak wrote: > On Wed, Nov 4, 2009 at 10:02 AM, jon wrote: > > > Hi, > > > I just noticed OrderBy statements cause Inner selects to break in h2: > > > I query such as: User.findAll(In(User.

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

On Wed, Nov 4, 2009 at 10:02 AM, jon wrote: > > Hi, > > I just noticed OrderBy statements cause Inner selects to break in h2: > > I query such as: User.findAll(In(User.id, Dog.owner, OrderBy(Dog.name, > Ascending)), MaxRows(5)) > > Produces: > > Message: org.h2.jdbc.JdbcSQLException: Order by exp

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

On Wed, Nov 4, 2009 at 11:04 AM, jon wrote: > > Wow, congrats! > No... not that way... I've got 5 year old twins... but our nanny's on vacation and my wife is way too busy on a huge case, so I'm primary childcare. > > On Nov 4, 1:46 pm, David P

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

Wow, congrats! On Nov 4, 1:46 pm, David Pollak wrote: > On Wed, Nov 4, 2009 at 10:36 AM, jon wrote: > > > That would be great.  Would it also be published to the scala-tools > > repo? > > Dunno.  Got to figure out how to get it published.  But we can work on that > tomorrow (today's release day

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

On Wed, Nov 4, 2009 at 10:36 AM, jon wrote: > > That would be great. Would it also be published to the scala-tools > repo? > Dunno. Got to figure out how to get it published. But we can work on that tomorrow (today's release day, plus I turn into a dad @ 1pm PST) > > On Nov 4, 1:18 pm, Davi

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

That would be great. Would it also be published to the scala-tools repo? On Nov 4, 1:18 pm, David Pollak wrote: > On Wed, Nov 4, 2009 at 10:02 AM, jon wrote: > > > Hi, > > > I just noticed OrderBy statements cause Inner selects to break in h2: > > > I query such as: User.findAll(In(User.id, Do

[Lift] Re: 1.1-SNAPSHOT In() with OrderBy mapper bug

On Wed, Nov 4, 2009 at 10:02 AM, jon wrote: > > Hi, > > I just noticed OrderBy statements cause Inner selects to break in h2: > > I query such as: User.findAll(In(User.id, Dog.owner, OrderBy(Dog.name, > Ascending)), MaxRows(5)) > > Produces: > > Message: org.h2.jdbc.JdbcSQLException: Order by exp

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

David, I opened ticket # 151. And I have some test cases written for uppercase dbTableName and dbColumnName. They are very simple-minded re-use of the Dog mapped class, but they do demostrate the same sort of failure behavior I was seeing in 1.1-SNAPSHOT, this time against the pre-145-fix source

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

Thanks for your support... and I'm very sorry to be the instigator of the breakage. I feel really bad that everything broke for all the MySQL and SQL server users (I gotta believe I'm not the only freak still using MySQL or SQL Server ;->) The only way to INTEGRATION test right now would be to ha

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

I'm going to revert the fix. I'm going to add tests for mixed-case column and table names. If you care to donate some of these tests, that'd be great. Please open a ticket. On Sat, Oct 31, 2009 at 5:35 AM, Troy Noble wrote: > After the fix, I'm having a different problem now with latest 1.1-S

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

After the fix, I'm having a different problem now with latest 1.1-SNAPSHOT (10/30 1:54:48PM build) with tables in the DB that have uppercase anywhere in either the dbTableName or dbColumnName name... the Mapper is creating SQL that throws exceptions due to unknown column in MySQL (which is case sen

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

On Fri, Oct 30, 2009 at 3:06 PM, Troy Noble wrote: > Thanks. I'll give it try. Dumb newbie question though... how do I access > the update? Git + build from github, or can I just grab the latest > 1.1-SNAPSHOT? > Check http://hudson.scala-tools.org/job/Lift/ You can see if the latest has buil

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

Thanks. I'll give it try. Dumb newbie question though... how do I access the update? Git + build from github, or can I just grab the latest 1.1-SNAPSHOT? Thanks again, Troy On Fri, Oct 30, 2009 at 3:01 PM, David Pollak wrote: > Turns out this was the problem. Some RDBMSs are case insensitive

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

Turns out this was the problem. Some RDBMSs are case insensitive on table/column names... others are not. I committed a fix (now on master thanks to fast review board turn-around) that causes all table and column names to lower case for all SQL transactions. 2009/10/30 Marcin Mielżyński > > I

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

I have seen EXACTLY same behavior when dbColumnName returned _upcased_ names lopex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsub

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

Certainly. I will open a ticket. I might have found 3 different issues... (one each for Mapper, schemify, CRUDify) all related to dbColumnName (see details below). I created a new scaled down project against 1.1-SNAPSHOT and an embedded Derby database, and it exhibits the Mapper dbColumnName beh

[Lift] Re: 1.1-M6 Mapped fields with dbColumnName always displaying defaultValue

On Thu, Oct 29, 2009 at 10:15 PM, Troy Noble wrote: > > We are using Mapper with a legacy database with many columns that we > are not allowed to rename in our database. For example CREATE_DATE > for which we created the following seemingly simple mapped field in > our model: > > object createD

[Lift] Re: 1.1

Your welcome Jack. Have fun. Cheers, Tim On 25 Oct 2009, at 18:28, Jack Widman wrote: > Thanks Tim. And next time I will search more before asking. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To

[Lift] Re: 1.1

Thanks Tim. And next time I will search more before asking. On Sun, Oct 25, 2009 at 2:26 PM, Timothy Perrett wrote: > > Jack, > > This question has been asked quite a number of times recently on list. > > Change: > > 1.0 > > on the liftweb dependencies in your pom.xml to be: > > 1.1-SNAPSHOT > >

[Lift] Re: 1.1

Jack, This question has been asked quite a number of times recently on list. Change: 1.0 on the liftweb dependencies in your pom.xml to be: 1.1-SNAPSHOT That will give you the latest HEAD build. If you want a known point in time, use M6: 1.1-M6 Cheers, Tim On Oct 25, 6:00 pm, jack wrote:

[Lift] Re: 1.1-SNAPSHOT and Snippet problems?

Anyways, I was definitely screwed up ... forcing maven to actually do what it was supposed to fixed my problem. Thanks for the pointer Marius. ~Thomas On Sat, Oct 3, 2009 at 5:39 PM, Thomas Rampelberg wrote: > I thought that I'd just updated all the versions . from that stack > trace, how d

[Lift] Re: 1.1-SNAPSHOT and Snippet problems?

I thought that I'd just updated all the versions . from that stack trace, how do you tell which version lift-util is? On Sat, Oct 3, 2009 at 1:39 PM, marius d. wrote: > > What verions of lift are you using? It appears that lift-util is a > different version than lift ? > > Br's, > Marius > >

[Lift] Re: 1.1-SNAPSHOT and Snippet problems?

What verions of lift are you using? It appears that lift-util is a different version than lift ? Br's, Marius On Oct 3, 11:11 pm, Thomas Rampelberg wrote: > I just synced up to main this morning and now whenever I try and use > one of my snippets, I'm getting the traceback below. Any hints on w

[Lift] Re: 1.1-SNAPSHOT broken in Google App Engine

I was able to confirm that clearing the cookie gets rid of the ClassNotFoundException. I have a hypothesis as to what happened: It appears that sometime after the M4 milestone, the SessionToServletBridge moved from the net.liftweb.http package to net.liftweb.http.provider.servlet. So, the M4 vers

[Lift] Re: 1.1-SNAPSHOT broken in Google App Engine

I was able to confirm that clearing the cookie gets rid of the ClassNotFoundException. I have a hypothesis as to what happened: It appears that sometime after the M4 milestone, the SessionToServletBridge moved from the net.liftweb.http package to net.liftweb.http.provider.servlet. So, the M4 vers

[Lift] Re: 1.1-SNAPSHOT broken in Google App Engine

Thanks for taking a look at this issue. If the solution is as simple as clearing/removing a cookie, that's great news. I'll give it a try and let you know how it worked. Thanks again! - Mark On Aug 26, 2:57 am, Atsuhiko Yamanaka wrote: > Hi, > > On Mon, Aug 17, 2009 at 9:18 AM, Mark Tye wrote:

[Lift] Re: 1.1-SNAPSHOT issue?

Many thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups

[Lift] Re: 1.1-SNAPSHOT issue?

Thanks. Added a test. Lift failed the test. Fixed Lift. Pushed the source to GitHub. On Thu, Aug 27, 2009 at 12:15 AM, E. Biggs wrote: > > Ok here's the problem stripped down. The merge happens but the > node isn't being removed from the body > Let me know if you'd like it in some other for

[Lift] Re: 1.1-SNAPSHOT issue?

Ok here's the problem stripped down. The merge happens but the node isn't being removed from the body Let me know if you'd like it in some other format. templates-hidden/outer.html: inner.html: Inner renders: Inner Inner

[Lift] Re: 1.1-SNAPSHOT issue?

David Pollak writes: > I've just pushed a new version live that will behave more gracefully if the > xsd cannot be loaded. I haven't looked at the new validation code, but if it fetches the DTD directly from the URL, we might consider using a local copy for a number of reasons: 1) It doesn't c

[Lift] Re: 1.1-SNAPSHOT issue?

On Wed, Aug 26, 2009 at 8:32 PM, E. Biggs wrote: > > Thanks David! My pages now render - although broken... the cause > appears to be a failed head merge between my template's head and the > surrounding template's head. Can you post an example of the failing use case and I'll roll it into our

[Lift] Re: 1.1-SNAPSHOT issue?

Thanks David! My pages now render - although broken... the cause appears to be a failed head merge between my template's head and the surrounding template's head. On Aug 26, 7:51 pm, David Pollak wrote: > I've just pushed a new version live that will behave more gracefully if the > xsd cannot b

[Lift] Re: 1.1-SNAPSHOT issue?

I've just pushed a new version live that will behave more gracefully if the xsd cannot be loaded. On Wed, Aug 26, 2009 at 7:39 PM, Justin Reardon wrote: > > Probably caused by this if you're in a dev environment: > http://groups.google.com/group/liftweb/t/90750187a6c29c2c > > On Aug 26, 9:36 pm,

[Lift] Re: 1.1-SNAPSHOT issue?

Probably caused by this if you're in a dev environment: http://groups.google.com/group/liftweb/t/90750187a6c29c2c On Aug 26, 9:36 pm, "E. Biggs" wrote: > Hi there, > > I just did a mvn -U jetty:run > > and my site that I know was working fine before is now broken with > this error displayed in t

[Lift] Re: 1.1-SNAPSHOT broken in Google App Engine

Hi, On Mon, Aug 17, 2009 at 9:18 AM, Mark Tye wrote: ... > I don't know if compatibility with App Engine is a priority for the > Lift team, but if this doesn't get fixed, I face an ugly choice > between remaining frozen at 1.1-M4 as Lift development moves forward, > or migrating away from App Eng

[Lift] Re: 1.1-SNAPSHOT broken in Google App Engine

Hi, On Wed, Aug 26, 2009 at 6:35 AM, David Pollak wrote: > Atsuhiko-san, > > Have you seen this note on the Lift list? I have not seen such a note on this list yet and I had not tried 1.1-SNAPSHOT on GAE/J in these days, but today I tried it and have also encountered the reported problem. I'll

[Lift] Re: 1.1-SNAPSHOT API docs

The webkit docs are here: http://scala-tools.org/mvnsites-snapshots/liftweb/lift-webkit/scaladocs/inde x.html If you want to generate them locally, just download the lift src and run this from the top level directory: mvn install scala:doc Cheers, Tim On 28/04/2009 17:08, "Andrew Scherpbier"

[Lift] Re: 1.1-SNAPSHOT API docs

On Tue, Apr 28, 2009 at 9:08 AM, Andrew Scherpbier wrote: > > Are the 1.1-SNAPSHOT API docs online somewhere? http://scala-tools.org/mvnsites-snapshots/liftweb/lift-util/scaladocs/index.html http://scala-tools.org/mvnsites-snapshots/liftweb/lift-webkit/scaladocs/index.html etc. > If not, can

[Lift] Re: 1.1 lift idea: sync

On Wed, Mar 4, 2009 at 9:47 PM, Lee Mighdoll wrote: > I've been thinking about browser-server data sync for use in my next > project. Sync is potentially more interesting than RPC style ajax, > especially for rich clients, and I think sync could be a grand thing to add > to lift. > > The basic i